DocViewer

Páginas

www.xlibros.com

ANÁLISIS Y DISEÑO
DE SISTEMAS
O C T A V A E D I C I Ó N
KENNETH E. KENDALL
JULIE E. KENDALL
Rutgers University
School of Business–Camden
Camden, New Jersey
TRADUCTOR
Alfonso Vidal Romero Elizondo
Ingeniero en Sistemas Computacionales
Tecnológico de Monterrey - Monterrey
REVISORES TÉCNICOS
Humberto Cárdenas Anaya
Departamento de Tecnologías
de Información y Computación
División de Ingeniería y Arquitectura
ITESM - Campus Estado de México
Óscar Díaz Alcántara
Universidad Anáhuac del Sur
Prentice Hallwww.xlibros.com

Authorized translation from the English language edition entitled Systems Analysis and Design, 8th edition, by Kenneth Kendall & Julie Kendall,
published by Pearson Education, Inc., publishing as PRENTICE HALL, INC., Copyright © 2011. All rights reserved.
ISBN 9780136089162.
Traducción autorizada de la edición en idioma inglés titulada Systems Analysis and Design, 8ª edición, por Kenneth Kendall y Julie Kendall,
publicada por Pearson Education, Inc., publicada como PRENTICE HALL, INC., Copyright © 2011. Todos los derechos reservados.
Esta edición en español es la única autorizada.
Edición en español
Editor: Luis Miguel Cruz Castillo
e-mail: luis.cruz@pearsoned.com
Editor de desarrollo: Bernardino Gutiérrez Hernández
Supervisor de producción: Rodrigo Romero Villalobos
OCTAVA EDICIÓN, 2011
D.R. © 2011 por Pearson Educación de México, S.A. de C.V.
Atlacomulco 500-5o. piso
Col. Industrial Atoto
53519, Naucalpan de Juárez, Estado de México
Cámara Nacional de la Industria Editorial Mexicana. Reg. núm. 1031.
Prentice Hall es una marca registrada de Pearson Educación de México, S.A. de C.V.
Reservados todos los derechos. Ni la totalidad ni parte de esta publicación pueden reproducirse, registrarse o transmitirse, por un sistema de recu-
peración de información, en ninguna forma ni por ningún medio, sea electrónico, mecánico, fotoquímico, magnético o electroóptico, por fotocopia,
grabación o cualquier otro, sin permiso previo por escrito del editor.
El préstamo, alquiler o cualquier otra forma de cesión de uso de este ejemplar requerirá también la autorización del editor o de sus representantes.
ISBN VERSIÓN IMPRESA: 978-607-32-0577-1
ISBN VERSIÓN E-BOOK: 978-607-32-0578-8
ISBN E-CHAPTER: 978-607-32-0579-5
PRIMERA IMPRESIÓN
Impreso en México. Printed in Mexico.
1 2 3 4 5 6 7 8 9 0 - 13 12 11 10
Datos de catalogación bibliográfica
KENDALL, KENNETH E. Y KENDALL, JULIE E.
Páginas: 600
PEARSON EDUCACIÓN, México, 2011
ISBN: 978-607-32-0577-1
Área: Computación
Formato: 21 27 cm
Análisis y diseño de sistemas.
Octava edición
A la memoria de Julia A. Kendall y de Edward J. Kendall,
cuyos ejemplos de vida y trabajo conjunto siempre nos han inspirado.
www.pearsoneducacion.net ISBN: 978-607-32-0577-1
Prentice Hall
es una marca dewww.xlibros.com

MARCAS REGISTRADAS
DE LAS EMPRESAS
Apple y Macintosh son marcas registradas de Apple Computer. 1Password es marca registrada de Agile Web
Solutions. Bento es marca registrada de FileMaker. Dragon NaturallySpeaking es marca registrada de Nuance.
Dreamweaver, Adobe Flash y FormFlow son marcas registradas de Adobe Systems Incorporated. DEVONagent y
DEVONthink Professional Office son marcas registradas de DEVONtechnologies. Firefox es marca registrada de
Mozilla Foundation. Freeway Pro es marca registrada de Softpress Systems. HyperCase es marca registrada
de Raymond J. Barnes, Richard L. Baskerville, Julie E. Kendall y Kenneth E. Kendall. Microsoft Windows,
Microsoft Access, Microsoft Word, Microsoft PowerPoint, Microsoft Project, Microsoft Excel y Microsoft Visio
son marcas registradas de Microsoft Corporation. OmniFocus es marca registrada de The Omni Group. OmniGraffle
y OmniPlan son marcas registradas de The Omni Group. OmniPage es marca registrada de Nuance. Palm es marca
registrada de Palm, Inc. ProModel y Service Model son marcas registradas de ProModel Corporation. Things es
marca registrada de Cultured Code. VMware Fusion es marca registrada de VMware. Visible Analyst es marca
registrada de Visible Systems Corporation. WinFax Pro y Norton Internet Security son marcas registradas de
Symantec. Yojimbo es marca registrada de Bare Bones Software. Los demás productos y nombres de empresas que
se mencionen en este libro pueden ser marcas registradas de sus respectivos propietarios. Las empresas, nombres
y/o datos utilizados en las pantallas y resultados de ejemplo son ficticios, a menos que se indique lo contrario.
vwww.xlibros.com

RESUMEN
DE CONTENIDO
PARTE I FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
1 SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 1
2 COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 24
3 ADMINISTRACIÓN DE PROYECTOS 56
PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
4 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 103
5 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 131
6 MODELADO ÁGIL Y PROTOTIPOS 155
PARTE III EL PROCESO DE ANÁLISIS
7 USO DE DIAGRAMAS DE FLUJO DE DATOS 193
8 ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 228
9 ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 259
10 ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 281
PARTE IV LOS FUNDAMENTOS DEL DISEÑO
11 DISEÑO DE UNA SALIDA EFECTIVA 329
12 DISEÑO DE UNA ENTRADA EFECTIVA 371
13 DISEÑO DE BASES DE DATOS 403
14 INTERACCIÓN HUMANO-COMPUTADORA 441
PARTE V ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
15 DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 485
16 ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 515
GLOSARIO 557
ACRÓNIMOS 565
ÍNDICE 566
viwww.xlibros.com

CONTENIDO
PARTE I FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS 1
1 SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 1
Tipos de sistemas 2
Sistemas de procesamiento de transacciones 2 / Sistemas de automatización de oficinas y sistemas
de trabajo de conocimiento 2 / Sistemas de información administrativa 3 / Sistemas de soporte de
decisiones 3 / Inteligencia artificial y sistemas expertos 3 / Sistemas de soporte de decisiones en grupo y
sistemas de trabajo colaborativo asistido por computadora 3 / Sistemas de soporte para ejecutivos 4
Integración de las tecnologías en sistemas 4
Las aplicaciones de comercio electrónico y los sistemas Web 4 / Sistemas empresariales 5 / Sistemas para
dispositivos inalámbricos y móviles 5 / Software de código fuente abierto 5
Necesidad del análisis y diseño de sistemas 6
Roles del analista de sistemas 6
El analista de sistemas como consultor 6 / El analista de sistemas como experto de soporte 6 / El analista de
sistemas como agente de cambio 7
Oportunidad de consultoría 1.1 Contratación saludable: se solicita ayuda para el comercio electrónico 7
Cualidades del analista de sistemas 8
El ciclo de vida del desarrollo de sistemas 8
Incorporación de las consideraciones de la interacción humano-computadora 9 / Identificación de los problemas,
oportunidades y objetivos 9 / Determinación de los requerimientos de información del factor humano 10 /
Análisis de las necesidades del sistema 10 / Diseño del sistema recomendado 11 / Desarrollo y documentación
del software 11 / Prueba y mantenimiento del sistema 11 / Implementación y evaluación del sistema 11
ATRACTIVO DE LA MAC 12
El impacto del mantenimiento 12
Uso de Herramientas Case 14
La metodología ágil 14
Proceso de desarrollo para un proyecto ágil 15
Análisis y diseño de sistemas orientado a objetos 17
Cómo elegir qué método de desarrollo de sistemas usar 19
RESUMEN 19
EXPERIENCIA DE HYPERCASE® 1 20
PALABRAS CLAVE Y FRASES 21
PREGUNTAS DE REPASO 21
BIBLIOGRAFÍA SELECCIONADA 21
EPISODIO 1 CASO DE LA CPU Se abre el caso 23
viiwww.xlibros.com

2 COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 24
Las organizaciones como sistemas 24
Capacidad de interrelación e interdependencia de los sistemas 25
Oportunidad de consultoría 2.1 La E de la vitamina E significa E-commerce (comercio electrónico) 26
Organizaciones y equipos virtuales 26 / Una perspectiva de sistemas 27 / Sistemas empresariales:
considerar a la organización como un sistema 28
Descripción gráfica de los sistemas 29
Los sistemas y el diagrama de flujo de datos a nivel de contexto 29 / Los sistemas y el modelo
de entidad-relación 30
ATRACTIVO DE LA MAC 35
Modelado de casos de uso 35
Símbolos de los casos de uso 36 / Relaciones de los casos de uso 36 / Desarrollo del alcance
del sistema 38 / Desarrollo de diagramas de casos de uso 38 / Desarrollo de escenarios de
casos de uso 38 / Niveles de los casos de uso 39 / Creación de las descripciones de los casos
de uso 43 / Por qué son útiles los diagramas de casos de uso 43
Niveles de administración 43
Oportunidad de consultoría 2.2 Donde hay carbón hay una copia 44
Implicaciones para el desarrollo de sistemas de información 45
Cultura organizacional 45
Oportunidad de consultoría 2.3 El poder de la pirámide 46
RESUMEN 46
EXPERIENCIA DE HYPERCASE® 2 47
PALABRAS CLAVE Y FRASES 48
PREGUNTAS DE REPASO 48
PROBLEMAS 48
PROYECTOS EN GRUPO 49
BIBLIOGRAFÍA SELECCIONADA 50
EPISODIO 2 CASO DE LA CPU Descripción gráfica de las relaciones 51
3 ADMINISTRACIÓN DE PROYECTOS 56
Iniciación del proyecto 56
Problemas en la organización 57 / Definición del problema 57
Oportunidad de consultoría 3.1 El sonido más dulce que haya sorbido 58
Selección de proyectos 61
Determinación de la viabilidad 62
Determinar si es posible o no 62
Determinación de las necesidades de hardware y software 63
Hacer un inventario del hardware computacional 64 / Estimación de las cargas de trabajo 64 / Evaluación
del hardware computacional 65 / Adquisición del equipo computacional 66 / Evaluación de software 68
OPORTUNIDAD DE CONSULTORÍA 3.2 Veni, Vidi, Vendi (Vine, vi y vendí) 70
Identificación, pronóstico y comparación de los costos y beneficios 72
Pronósticos 72 / Identificación de los beneficios y costos 72
Oportunidad de consultoría 3.3 Vamos a ver a los magos 73
Comparación de los costos y beneficios 74
Planeación y control de actividades 77
Estimación del tiempo requerido 77
viii CONTENIDOwww.xlibros.com

Oportunidad de consultoría 3.4 Alimento para el pensamiento 78
Uso de gráficos de Gantt para programar proyectos 79 / Uso de diagramas PERT 80
Administración del proyecto 82
Cómo lidiar con la complejidad del sistema 82
ATRACTIVO DE LA MAC 83
Administración de las actividades de análisis y diseño 83
Ensamblar un equipo 83
EXPERIENCIA DE HYPERCASE® 3.1 84
Estrategias de comunicación para administrar equipos 84 / Establecer objetivos de
productividad del proyecto 85
Oportunidad de consultoría 3.5 Cuidar los objetivos 85
Motivación de los miembros del equipo del proyecto 86 / Administración de proyectos de comercio
electrónico 86 / Creación de los estatutos del proyecto 87 / Cómo evitar fracasos en los proyectos 87
La propuesta de sistemas 88
Organización de la propuesta de sistemas 88 / Uso de figuras para una comunicación efectiva 89
RESUMEN 91
EXPERIENCIA DE HYPERCASE® 3.2 92
PALABRAS CLAVE Y FRASES 93
PREGUNTAS DE REPASO 93
PROBLEMAS 94
PROYECTOS EN GRUPO 98
BIBLIOGRAFÍA SELECCIONADA 98
EPISODIO 3 CASO DE LA CPU Llegar a conocerte 100
PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN 103
4 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 103
Entrevistas 103
Los cinco pasos para la preparación de una entrevista 104 / Tipos de preguntas 105
Ordenar las preguntas en una secuencia lógica 107
Oportunidad de consultoría 4.1 Fortalezca sus tipos de preguntas 108
Cómo escribir el informe de la entrevista 109
Oportunidad de consultoría 4.2 Un vistazo a la superficie 110
Diseño de aplicación conjunta 111
Condiciones que respaldan el uso de JAD 111 / ¿Quién está involucrado? 111
EXPERIENCIA DE HYPERCASE® 4.1 112
Ubicación de las reuniones JAD 112
Oportunidad de consultoría 4.3 Analista de sistemas, supongo 113
Obtención de un análisis estructurado de las actividades del proyecto 113 / Beneficios potenciales al usar
JAD en vez de las entrevistas tradicionales 113 / Desventajas potenciales de JAD 113
Uso de cuestionarios 114
Planeación del uso de cuestionarios 114 / Escribir las preguntas 115 / Uso de escalas en los cuestionarios 118
Diseño de los cuestionarios 119
Oportunidad de consultoría 4.4 El cuestionario insoportable 120
Oportunidad de consultoría 4.5 Orden en las cortes 121
Administración de los cuestionarios 122
RESUMEN 122
CONTENIDO ixwww.xlibros.com

EXPERIENCIA DE HYPERCASE® 4.2 123
PALABRAS Y FRASES CLAVE 123
PREGUNTAS DE REPASO 124
PROBLEMAS 124
PROYECTOS EN GRUPO 127
BIBLIOGRAFÍA SELECCIONADA 127
EPISODIO 4 CASO DE LA CPU Escucharé ahora, pregunto después 128
5 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 131
Muestreo 131
La necesidad del muestreo 132 / Diseño del muestreo 132 / La decisión sobre el tamaño de las muestras 134
Oportunidad de consultoría 5.1 A la caza de una muestra 135
Investigación 136
Análisis de documentos cuantitativos 136
Oportunidad de consultoría 5.2 Una rosa con otro nombre... o Calidad mejor que cantidad 137
Análisis de los documentos cualitativos 140
EXPERIENCIA DE HYPERCASE® 5.1 141
Observación del comportamiento del encargado de tomar decisiones 142
Observación de las actividades de toma de decisiones de un gerente común 142
Observación del entorno físico 142
Observación estructurada del entorno (STROBE) 142
Oportunidad de consultoría 5.3 No confíes en su autoestima o no todo se refleja en un espejo 145
Aplicación del método STROBE 146
ATRACTIVO DE LA MAC 147
RESUMEN 148
EXPERIENCIA DE HYPERCASE® 5.2 149
PALABRAS CLAVE Y FRASES 150
PREGUNTAS DE REPASO 150
PROBLEMAS 150
PROYECTOS EN GRUPO 152
BIBLIOGRAFÍA SELECCIONADA 153
EPISODIO 5 CASO DE LA CPU Ver es creer 154
6 MODELADO ÁGIL Y PROTOTIPOS 155
Prototipos 156
Tipos de prototipos 156 / Uso de prototipos como alternativa para el SDLC 157
Desarrollo de un prototipo 158
Lineamientos para desarrollar un prototipo 159
Oportunidad de consultoría 6.1 Los prototipos, ¿son los reyes? 159
Oportunidad de consultoría 6.2 Despejando el camino para los vínculos con los clientes 160
Desventajas de los prototipos 160 / Ventajas de los prototipos 161 / Creación de prototipos mediante
software COTS 161
Oportunidad de consultoría 6.3 Incubar un pez 161
Oportunidad de consultoría 6.4 Este prototipo está todo mojado 162
El papel que desempeñan los usuarios en los prototipos 162
x CONTENIDOwww.xlibros.com

Desarrollo rápido de aplicaciones 163
Fases de RAD 164 / Comparación entre RAD y el SDLC 165
Modelado ágil 166
Valores y principios del modelado ágil 166 / Actividades, recursos y prácticas del modelado ágil 168 / El
proceso de desarrollo ágil 171
ATRACTIVO DE LA MAC 173
Lecciones aprendidas a partir del modelado ágil 175
Comparación entre el modelado ágil y los métodos estructurados 176
Mejorar la eficiencia en el trabajo del conocimiento: comparación entre SDLC y el método ágil 177 /
Riesgos inherentes a la innovación organizacional 179
RESUMEN 181
EXPERIENCIA DE HYPERCASE ® 6 182
PALABRAS CLAVE Y FRASES 183
PREGUNTAS DE REPASO 183
PROBLEMAS 183
PROYECTOS EN GRUPO 185
BIBLIOGRAFÍA SELECCIONADA 185
EPISODIO 6 CASO DE LA CPU Tiempo de reacción 186
PARTE III EL PROCESO DE ANÁLISIS 193
7 USO DE DIAGRAMAS DE FLUJO DE DATOS 193
La metodología del flujo de datos para determinar los requerimientos humanos 193
Ventajas de la metodología del flujo de datos 193 / Convenciones usadas en los diagramas
de flujo de datos 194
Cómo desarrollar diagramas de flujos de datos 195
Creación del diagrama de contexto 195 / Dibujo del Diagrama 0 (el siguiente nivel) 196 / Creación de
diagramas hijos (niveles más detallados) 198 / Comprobación de errores en los diagramas 198
Diagramas de flujo de datos lógicos y físicos 200
Cómo desarrollar diagramas de flujo de datos lógicos 202 / Cómo desarrollar diagramas de flujo de datos
físicos 203 / Cómo particionar los diagramas de flujo de datos 206
Ejemplo de un diagrama de flujo de datos 207
Desarrollar la lista de actividades de negocios 207 / Crear un diagrama de flujo de datos a nivel de
contexto 208 / Dibujo del Diagrama 0 210 / Crear un diagrama hijo 211 / Crear un diagrama de flujo de
datos físico a partir del DFD lógico 212 / Cómo particionar el DFD físico 213
Particionamiento de sitios web 213
OPORTUNIDAD DE CONSULTORÍA 7.1 No hay negocio como el negocio de los flujos 216
Comunicación mediante el uso de diagramas de flujo de datos 217
RESUMEN 217
EXPERIENCIA DE HYPERCASE® 7 218
PALABRAS CLAVE Y FRASES 218
PREGUNTAS DE REPASO 219
PROBLEMAS 219
PROYECTOS EN GRUPO 221
BIBLIOGRAFÍA SELECCIONADA 221
EPISODIO 7 CASO DE LA CPU Siguiendo el flujo 222
CONTENIDO xiwww.xlibros.com

8 ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 228
El diccionario de datos 228
Necesidad de comprender el diccionario de datos 229
El repositorio de datos 229
Definición de los flujos de datos 230 / Descripción de las estructuras de datos 231 / Estructuras de datos
lógicas y físicas 233 / Elementos de datos 234 / Almacenes de datos 236
Creación del diccionario de datos 238
Análisis de la entrada y la salida 239
Oportunidad de consultoría 8.1 ¿Deseas triunfar en el teatro? ¡Mejora tu dicción(ario)! 240
Desarrollo de almacenes de datos 241
Uso del diccionario de datos 242
Uso de diccionarios de datos para crear XML 243 / Definiciones de tipo de documento de XML 244 /
Esquemas de XML 246
EXPERIENCIA DE HYPERCASE® 8 247
RESUMEN 248
PALABRAS CLAVE Y FRASES 248
PREGUNTAS DE REPASO 248
PROBLEMAS 249
PROYECTOS EN GRUPO 251
BIBLIOGRAFÍA SELECCIONADA 251
EPISODIO 8 Caso de la CPU Definir lo que queremos decir 252
9 ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 259
Generalidades de las especificaciones de los procesos 259
Formato de especificación de proceso 260
Español estructurado 261
Cómo escribir español estructurado 261
Oportunidad de consultoría 9.1 Kit Chen Kaboodle, Inc. 263
Oportunidad de consultoría 9.2 Estructura para amasar 264
Diccionario de datos y especificaciones de procesos 265
Tablas de decisión 266
Desarrollar tablas de decisión 267
Oportunidad de consultoría 9.3 Ahorrar un centavo en Citron Car Rental 269
Verificar la integridad y precisión 270
Árboles de decisión 271
Oportunidad de consultoría 9.4 Un árbol gratis 272
Dibujar árboles de decisión 272
Cómo elegir una técnica de análisis de decisiones estructuradas 273
RESUMEN 273
EXPERIENCIA DE HYPERCASE® 9 274
PALABRAS CLAVE Y FRASES 274
PREGUNTAS DE REPASO 274
PROBLEMAS 274
PROYECTOS EN GRUPO 276
BIBLIOGRAFÍA SELECCIONADA 276
EPISODIO 9 CASO DE LA CPU Presentar una decisión 277
xii CONTENIDOwww.xlibros.com

10 ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 281
Conceptos orientados a objetos 282
Objetos 282 / Clases 282 / Herencia 283
Oportunidad de consultoría 10.1 Alrededor del mundo en 80 objetos 284
Tarjetas CRC y pensamiento en objetos 284
Interacción durante una sesión CRC 284
Conceptos y diagramas del lenguaje unificado de modelado (UML) 286
Modelado de casos de uso 287
Diagramas de actividad 290
Creación de diagramas de actividad 292
Oportunidad de consultoría 10.2 Reciclando el entorno de programación 293
Entradas en el repositorio para un diagrama de actividad 294
Diagramas de secuencia y de comunicación 294
Diagramas de secuencia 294 / Diagramas de comunicación 296
Diagramas de clases 297
Sobrecarga de métodos 298 / Tipos de clases 299 / Definición de mensajes y métodos 300
Cómo mejorar los diagramas de secuencia 300
Un ejemplo de clase para Web 300 / Las capas de presentación, negocios y persistencia
en los diagramas de secuencia 302
Cómo mejorar los diagramas de clases 303
Relaciones 304 / Diagramas de generalización/especialización (gen/spec) 306
Diagramas de estados 309
Ejemplo de una transición de estado 310
Paquetes y otros artefactos de UML 311
Oportunidad de consultoría 10.3 Desarrollo de un sistema fino cuyo plazo de entrega se venció hace
mucho: uso del análisis orientado a objetos para el Sistema de la biblioteca pública Ruminski 313
Ponga el UML a trabajar 313
Oportunidad de consultoría 10.4 C-Shore 315
La importancia de usar UML para el modelado 315
RESUMEN 316
EXPERIENCIA DE HYPERCASE® 10 317
PALABRAS CLAVE Y FRASES 317
PREGUNTAS DE REPASO 318
PROBLEMAS 318
BIBLIOGRAFÍA SELECCIONADA 319
EPISODIO 10 CASO DE LA CPU Objetos con clase 320
PARTE IV LOS FUNDAMENTOS DEL DISEÑO 329
11 DISEÑO DE UNA SALIDA EFECTIVA 329
Objetivos de diseño de la salida 329
Diseñar la salida para servir al propósito previsto 329 / Diseñar la salida para ajustarla
al usuario 330 / Entregar la cantidad apropiada de salida 330 / Asegurarse que la salida
esté donde se necesite 330 / Proveer la salida en forma oportuna 330 / Elegir el método
de salida correcto 330
CONTENIDO xiiiwww.xlibros.com

Relacionar el contenido de la salida con el método de salida 330
Tecnologías de salida 331
Oportunidad de consultoría 11.1 ¿Tu jaula o la mía? 335
Factores a considerar al elegir la tecnología de salida 336
Oportunidad de consultoría 11.2 Una vía correcta, una equivocada y una vía de metro 339
Comprender cómo afecta la predisposición en la salida a los usuarios 340
Cómo reconocer la predisposición en la forma en que se utiliza la salida 340 / Cómo evitar la predisposición
al diseñar la salida 341 / Cómo diseñar la salida impresa 341 / Lineamientos para el diseño de informes
impresos 341
Oportunidad de consultoría 11.3 ¿Debería prohibirse esta gráfica? 342
Cómo diseñar salida para pantallas 344
Lineamientos para el diseño de pantallas 344 / Uso de salida gráfica en el diseño de pantallas 345 /
Tableros de control 346 / Widgets y gadgets: modificación de la metáfora del escritorio 347
Oportunidad de consultoría 11.4 ¿Es tu trabajo aburrido? 348
Diseño de un sitio web 348
Lineamientos generales para diseñar sitios Web 349 / Mantenimiento de los sitios Web 356 / Creación de
blogs (Weblogs) 357
ATRACTIVO DE LA MAC 351
Oportunidad de consultoría 11.5 Un día en el campo 356
Producción de la salida y XML 357
Ajax 358
EXPERIENCIA DE HYPERCASE® 11 360
RESUMEN 360
PALABRAS CLAVE Y FRASES 361
PREGUNTAS DE REPASO 361
PROBLEMAS 362
PROYECTOS EN GRUPO 365
BIBLIOGRAFÍA SELECCIONADA 365
EPISODIO 11 CASO DE LA CPU Elaborar informes con base en las salidas 366
12 DISEÑO DE UNA ENTRADA EFECTIVA 371
Diseño de buenos formularios 371
Hacer que los formularios sean fáciles de llenar 372 / Cumplir con el propósito previsto 374 / Asegurar que
se llenen en forma precisa 375 / Mantener los formularios atractivos 375 / Cómo controlar los formularios
de las empresas 376
Diseño de buenos formularios web y de pantalla 376
Mantener la pantalla simple 376
Oportunidad de consultoría 12.1 Este formulario puede ser dañino para su salud 377
Mantener la pantalla consistente 378 / Facilitar el movimiento 378 / Diseñar una pantalla atractiva y
agradable 378 / Utilice iconos en el diseño de las pantallas 378 / Diseño de la interfaz gráfica de usuario 379
Oportunidad de consultoría 12.2 Tener todo junto no siempre es lo mejor 379
Controles y valores de los formularios 381 / Campos ocultos 382 / Tablas de respuesta
a eventos 382 / Páginas Web dinámicas 383 / Páginas Web tridimensionales 385 / Ajax (JavaScript
asíncrono y XML) 387 / Uso de color en el diseño de pantallas 389
Diseño de páginas de Intranet e Internet 389
Oportunidad de consultoría 12.3 Juego de máscaras 390
ATRACTIVO DE LA MAC 392
xiv CONTENIDOwww.xlibros.com

RESUMEN 392
EXPERIENCIA DE HYPERCASE® 12 393
PALABRAS CLAVE Y FRASES 394
PREGUNTAS DE REPASO 394
PROBLEMAS 395
PROYECTOS EN GRUPO 397
BIBLIOGRAFÍA SELECCIONADA 398
EPISODIO 12 CASO DE LA CPU Formando pantallas y visualizando formularios 399
13 DISEÑO DE BASES DE DATOS 403
Bases de datos 403
Oportunidad de consultoría 13.1 Enganche su carrito de limpieza a una estrella 404
Conceptos de datos 404
Realidad, datos y metadatos 405 / Archivos 410 / Bases de datos relacionales 411
Normalización 413
Los tres pasos de la normalización 413 / Un ejemplo de normalización 414 / Uso del diagrama
entidad-relación para determinar las claves de los registros 421 / Relación de uno a muchos 422 /
Relación de muchos a muchos 423
Lineamientos para el diseño de relaciones de archivos maestros/bases de datos 424
Restricciones de integridad 424
ATRACTIVO DE LA MAC 425
Anomalías 425
Uso de la base de datos 426
Pasos para recuperar y presentar los datos 426
Desnormalización 426
Almacenes corporativos de datos 429
Procesamiento analítico en línea 429 / Minería de datos 430
Oportunidad de consultoría 13.2 Almacenamiento de minerales para la salud, minería de datos 430
Oportunidad de consultoría 13.3 Pérdida de prospectos 431
RESUMEN 432
EXPERIENCIA DE HYPERCASE® 13 433
PALABRAS CLAVE Y FRASES 433
PREGUNTAS DE REPASO 434
PROBLEMAS 434
PROYECTO EN GRUPO 436
BIBLIOGRAFÍA SELECCIONADA 436
EPISODIO 13 CASO DE LA CPU De vuelta a los fundamentos de datos 437
14 INTERACCIÓN HUMANO-COMPUTADORA 441
Comprensión de la interacción humano-computadora 441
Cómo el ajuste afecta al desempeño y al bienestar 442 / El modelo de aceptación de la tecnología
y su relación con la actitud 443
Usabilidad 444
Diseño para los estilos cognoscitivos de usuarios individuales 444 / Consideraciones físicas en el diseño de
la HCI 448 / Consideración de las limitaciones, discapacidades y diseño de los humanos 449
Oportunidad de consultoría 14.1 El espíritu escolar viene en varias tallas 450
Implementación de las buenas prácticas de la HCI 450
CONTENIDO xvwww.xlibros.com

Tipos de interfaz de usuario 451
Interfaces de lenguaje natural 451 / Interfaces de preguntas y respuestas 452 / Menús 453
Oportunidad de consultoría 14.2 Preferiría hacerlo yo mismo 454
Interfaces de llenado de formularios (formularios de entrada/salida) 454 / Interfaces de lenguaje de
comandos 455
Oportunidad de consultoría 14.3 No me desaceleren 456
Interfaces gráficas de usuario 456 / Otras interfaces de usuario 457
Oportunidad de consultoría 14.4 Ésa no es una bombilla 457
Lineamientos para el diseño del diálogo 458
Comunicación significativa 459 / Mínima acción por parte del usuario 459 / Operación y consistencia
estándar 461
Oportunidad de consultoría 14.5 En espera de ser alimentado 461
Retroalimentación para los usuarios 461
Tipos de retroalimentación 462 / Incluir retroalimentación en el diseño 464
Consideraciones de diseño especiales para el comercio electrónico 465
Solicitar retroalimentación de los clientes del sitio Web de comercio electrónico 465 / Fácil navegación para
los sitios Web de comercio electrónico 465
Oportunidad de consultoría 14.6 Al correr en un maratón, es conveniente saber hacia
dónde se dirige 466
ATRACTIVO DE LA MAC 467
Aplicaciones web híbridas (MASHUPS) 468
Diseño de consultas 468
Tipos de consultas 469 / Métodos de consulta 471
Oportunidad de consultoría 14.7 ¡Eh, mírame! (Repetición) 472
RESUMEN 474
PALABRAS CLAVE Y FRASES 474
EXPERIENCIA DE HYPERCASE® 14 475
PREGUNTAS DE REPASO 476
PROBLEMAS 476
PROYECTOS EN GRUPO 477
BIBLIOGRAFÍA SELECCIONADA 478
EPISODIO 14 Caso de la CPU Depende de los usuarios 479
PARTE V ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 485
15 DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 485
Codificación efectiva 485
Mantener el registro de algo 486 / Clasificar la información 487 / Ocultar información 488 / Revelar
información 489 / Unicode 490 / Solicitar la acción apropiada 491 / Lineamientos generales para la
codificación 491
Oportunidad de consultoría 15.1 Aquí parece una jungla 492
Oportunidad de consultoría 15.2 Pescar un código de verano 494
Captura de datos efectiva y eficiente 494
Qué capturar 494 / Dejar que la computadora haga el resto 495 / Cómo evitar cuellos de botella y pasos
adicionales 496 / Empezar con un buen formulario 496 / Elegir un método de entrada de datos 496
xvi CONTENIDOwww.xlibros.com

Oportunidad de consultoría 15.3 Entrar o no entrar: esa es la cuestión 499
Asegurar la calidad de los datos por medio de la validación de la entrada 499
Validar las transacciones de entrada 500 / Validar los datos de entrada 500
Oportunidad de consultoría 15.4 ¿Validan el estacionamiento? 504
El proceso de validación 505
Ventajas de la precisión en los entornos de comercio electrónico 506
Los clientes teclean sus propios datos 506 / Almacenar datos para su uso posterior 506 / Utilizar datos por
medio del proceso de cumplimiento de pedidos 506 / Proveer retroalimentación a los clientes 506
EXPERIENCIA DE HYPERCASE® 15 507
RESUMEN 507
PALABRAS CLAVE Y FRASES 508
PREGUNTAS DE REPASO 508
PROBLEMAS 509
PROYECTOS EN GRUPO 511
BIBLIOGRAFÍA SELECCIONADA 511
EPISODIO 15 Caso de la CPU Introducir en forma natural 512
16 ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 515
La metodología de administración de la calidad total 516
Seis Sigma 516 / Responsabilidad de la administración de la calidad total 516 / Recorrido estructurado 517
Oportunidad de consultoría 16.1 La calidad de MIS no se pone a prueba 518
Diseño y desarrollo de sistemas descendente 518
ATRACTIVO DE LA MAC 520
Uso de diagramas de estructura para diseñar sistemas modulares 520 / Arquitectura orientada a servicios
(SOA) 522
Metodologías de documentación 523
Manuales de procedimientos 523 / El método FOLKLORE 523
Oportunidad de consultoría 16.2 Escribir está bien 524
EXPERIENCIA DE HYPERCASE® 16.1 525
Elección de una técnica de diseño y documentación 526
Prueba, mantenimiento y auditoría 526
El proceso de prueba 526
Oportunidad de consultoría 16.3 Estudiando de manera intensiva para su prueba de sistemas 528
Prácticas de mantenimiento 528 / Auditoría 529
Implementación de sistemas distribuidos 529
Tecnología cliente-servidor 529 / Computación en nube 531 / Modelado de red 533
Capacitación de usuarios 536
Estrategias de capacitación 537 / Lineamientos para la capacitación 537
Oportunidad de consultoría 16.4 Puede guiar un pez al agua... pero no puede hacer
que la tome 538
Conversión a un nuevo sistema 539
Estrategias de conversión 539 / Otras consideraciones de conversión 540 / Metáforas organizacionales y su
relación con los sistemas exitosos 541
Aspectos de seguridad para los sistemas tradicionales y los basados en web 542
Seguridad física 542 / Seguridad lógica 542 / Seguridad conductual 543 / Consideraciones especiales de
seguridad para el comercio electrónico 543 / Consideraciones de privacidad para el comercio
electrónico 544 / Planeación de recuperación de desastres 544
CONTENIDO xviiwww.xlibros.com

Oportunidad de consultoría 16.5 El dulce aroma del éxito 546
Evaluación 546
Técnicas de evaluación 546 / El enfoque de utilidad del sistema de información 546
Oportunidad de consultoría 16.6 Limpiando el nuevo sistema 548
Evaluación de sitios web corporativos 548
RESUMEN 550
EXPERIENCIA DE HYPERCASE® 16.2 551
PALABRAS CLAVE Y FRASES 551
PREGUNTAS DE REPASO 551
PROBLEMAS 552
PROYECTOS EN GRUPO 554
BIBLIOGRAFÍA SELECCIONADA 554
EPISODIO 16 CASO DE LA CPU Semper Redundate 555
GLOSARIO 557
ACRÓNIMOS 565
ÍNDICE 566
xviii CONTENIDOwww.xlibros.com

PREFACIO
NOVEDADES DE ESTA EDICIÓN
La octava edición de Kendal y Kendall: Análisis y diseño de sistemas incluye ciertos cambios sustanciales obliga-
torios debido a las rápidas transformaciones ocurridas en el campo de los sistemas de información (IS) durante los
últimos tres años, y se incluyen como respuesta a la aportación de nuestros seguidores, estudiantes y revisores.
A lo largo del libro se integran muchas características nuevas y otras se han actualizado. La siguiente lista muestra
las novedades específicas:
Se introducen tres metodologías en los primeros capítulos: SDLC, metodologías ágiles y el análisis y di-
seño de sistemas orientados a objetos con UML, junto con los motivos y las situaciones que indican
cuándo utilizarlos (capítulo 1).
Cobertura ampliada de COTS, un tipo de software cada vez más utilizado en las organizaciones (capítulo 3).
Mayor cobertura sobre el análisis y diseño orientados a objetos; inclusión del tema en la parte central del
texto con el fin de incorporar esta técnica más fácilmente en los proyectos del periodo escolar (capítulo 10).
Se incluyen nuevos problemas de análisis y diseño orientados a objetos en el caso de la CPU, Objetos con
clase (capítulo 10).
Una nueva característica en el texto titulada Atractivo de la Mac, que habla sobre el software innovador
disponible en estas computadoras.
Nueva cobertura sobre la computación en nube (capítulo 16).
Nueva sección sobre la SOA (arquitectura orientada a servicios) (capítulo 16).
Nuevas Preguntas de repaso, Problemas y Ejercicios en grupo al final de los capítulos.
Se reorganizó, actualizó y fortaleció el capítulo sobre los métodos ágiles (capítulo 6).
Para fortalecer la cobertura sobre la administración de proyectos presentamos los estatutos del proyecto
durante las primeras etapas del proceso (capítulo 3).
Presentamos un poco antes que en la edición anterior la forma de preparar la proposición de sistemas
(capítulo 3).
Se actualizaron y optimizaron los Casos de la CPU, a lo largo del texto. Los estudiantes pueden utilizar
Microsoft Access, Microsoft Visio o Visible Analyst para completar las nuevas asignaturas en el texto.
Se actualizaron los escenarios, problemas y gráficos a lo largo del texto para acompañar a HyperCase 2.8,
una simulación gráfica para la Web que permite a los estudiantes aplicar sus nuevas habilidades.
CARACTERÍSTICAS DE DISEÑO
Las figuras tienen una apariencia estilizada para ayudar a que los estu-
diantes capten con mayor facilidad el tema en cuestión.
Se utilizan diagramas conceptuales para presentar las diversas he-
rramientas que los analistas de sistemas tienen a su disposición. Este
ejemplo muestra las diferencias entre los diagramas de flujo de datos
lógico y los diagramas de flujo de datos físico. Los diagramas concep-
tuales están codificados por colores para que sus funciones se distingan
claramente y los estudiantes puedan identificar sus elementos con faci-
lidad. Se ilustran muchas otras herramientas importantes, incluyendo los
diagramas de caso-uso, los diagramas de secuencia y los diagramas de
clases.
xix
Artículos y precios
Cliente
Identificar
artículo
1
D1 Precios
Artículos por
comprar
Precios
Buscar
precios
2
ID de artículo Cantidad a pagarCalcular el
costo total
del pedido
3
Recibo
Saldar
transacción y
emitir recibo
4
Cliente
Pago
Diagrama de flujo de datos lógico
Códigos y precios
de artículos
Cliente
Pasar
artículo por
el escáner
(manual)
1
D1 Archivo de precios UPC Archivo de trans.
temporal
Artículos
a pagar
Descripción y precios
del artículo
Buscar código
y precio en
el archivo
2
Código de
barras UPC
Monto calculado
a pagarCalcular
costo
total
3
Recibo
de la caja
registradora
Recibir dinero
y dar
recibo
(manual)
4
Cliente
Efectivo,
cheque o
tarjeta de
débito
Diagrama de flujo de datos físico
Código UPC
D2
Artículos, precios
y subtotales
Artículos y
precioswww.xlibros.com

Las pantallas de computadora muestran características importantes
del software que son útiles para el analista. Este ejemplo indica cómo se
pueden evaluar los vínculos rotos en un sitio Web mediante un paquete
como Microsoft Visio. Las pantallas de computadora muestran aspectos
importantes del diseño. Los analistas siempre están buscando mejorar la
apariencia de las pantallas y las páginas Web que diseñan. Los coloridos
ejemplos ayudan a ilustrar por qué algunas pantallas de diseño son especial-
mente efectivas.
Los formularios de papel se utilizan durante el proceso para mostrar
el diseño de las entradas y salidas, así como el diseño de los cuestionarios.
Siempre se utiliza tinta azul para la escritura o la introducción de datos,
de manera que sea fácil identificar qué es lo que los usuarios llenaron.
Aunque la mayoría de las organizaciones tienen como objetivo computari-
zar los procesos manuales en un momento dado, gran parte de la captura de
datos se realiza aún a través de formularios de papel. El diseño de formula-
rios mejorados permite a los analistas asegurar datos precisos y completos
de entrada y salida. Los formularios mejorados también ayudan a optimizar
los nuevos flujos de trabajo internos que se producen debido a las aplica-
ciones de negocio a consumidor (B2C) recién automatizadas para el comer-
cio electrónico en la Web.
Las tablas se utilizan cuando una lista importante necesita atención
especial, o cuando es necesario organizar o clasificar información. También
se utilizan para complementar la comprensión del lector de una manera
distinta a la forma en que el material se organiza en el cuerpo del texto. La
mayoría de los analistas encuentra que las tablas son una forma útil de or-
ganizar los números y el texto en una “instantánea” significativa.
El siguiente ejemplo de una tabla del capítulo 3 muestra la forma en que los analistas pueden refinar sus planes
de actividad para el análisis si los desglosan en tareas más pequeñas y luego
estiman el tiempo requerido para completarlas. La filosofía subyacente de
nuestro libro es que el análisis y diseño de sistemas es un proceso que inte-
gra el uso de muchas herramientas con los talentos únicos del analista de
sistemas para mejorar de manera sistemática la actividad comercial, a tra-
vés de la implementación o modificación de los sistemas de información
computarizados. Los analistas de sistemas pueden mejorar en su trabajo al
asumir nuevos retos de TI y mantenerse actualizados en su profesión me-
diante la aplicación de nuevas técnicas y herramientas.
UN BREVE PASEO POR LA OCTAVA EDICIÓN
xx PREFACIO
8
y después
estimar el
tiempo requerido.
Realizar entrevistas
Administrar cuestionarios
Leer informes de la compañía
Introducir el prototipo
Observar las reacciones al prototipo
Analizar el flujo de datos
Realizar el análisis de costo-beneficio
Preparar la propuesta
Presentar la propuesta
Recopilación de datos
Análisis de flujo de datos y decisiones
Preparación de la propuesta
3
4
4
5
3
3
2
2
Semanas
requeridasActividad detalladaActividad
Descomponer
éstos incluso
aún más
REGISTRO DE PAGO: Tot. 31175/0 + 81299 + Renta = 910
TOTAL DE PAGO INICIAL REQUERIDO:
855 55 910 H/S dep. 4
Fecha
venc.
Fecha
pago
Recibo
Núm.
Pago al
mediodía
Total
renta Segu-
ridad Lim-
pieza 31700
81299
Otros Monto
pagado Saldo
restanteImp.
Fechas
Monto
Descr.
Mont.
TV 10/ 3 MO! 8/28 8/28 106642 9/30 1031.32 202 115 44.20 25
414.82
15 1430.52 0
10/1 10/ 3 107503 10/31 910 910 0
11 / 1 11/ 1 10935 11/ 16 485.28 485.28 0
C1H/S9-16 11/17 11/8 11200 11/ 23 212.31 212.31 0
Cobrar 1 MES 11/24
Prorrateado
Hay que crear H/S
para reembolsar
depósito.
EDIFICIO # NOMBRE
Fecha original en que se mudó d Exp. x #
Renta
base Refri-
gerador Mue-
bles
Total
renta Segu-
ridad Lim-
pieza
31700
Imp.
Tarifa
diaria
8-28 igual 1
Kendall 1 ero
NOMBRE PROY. # FIRMA CLAVE
POTENCIAL RENTA 1175/0 81299
PRORRATEO
A/C Ser-
vicios HMSR T.V. Muca-
ma 31175/0 81299 Días Totales
POTENCIAL
DEPÓSITO
Depósitos
Sólo memo 31175/0
OAK. FC 562
H/S
rent 30. 33 1.30 910
39
200 115 31.63 340
1430.52
15 . 00
121 . 32
5 . 20
Trate de detectar
los lugares donde la
computadora pueda
simplificar el trabajo.
Observe el número y
tipo de transacciones
Verifique los errores.
Busque
oportunidades de
mejorar el diseño.
Parte I:
Fundamentos del
análisis de sistemas
Parte II:
Análisis de requerimientos
de información
Parte V:
Aseguramiento de
calidad e implementación
Parte III:
El proceso de análisis
Parte IV:
Fundamentos del diseñowww.xlibros.com

Por lo general, el análisis y diseño de sistemas se enseña en uno o dos semestres; nuestro libro se puede utilizar en
cualquiera de las dos situaciones. El texto es apropiado para los planes de estudios de licenciatura (de dos o cuatro
años) en carreras universitarias de cuatro años, escuelas de graduados o colegios comunitarios. El nivel y la longi-
tud del curso pueden variar y se pueden suplementar mediante proyectos reales, HyperCase u otros materiales
disponibles en el Centro de recursos para el profesor.
El texto se divide en cinco partes principales: Fundamentos del análisis de sistemas (parte I), Análisis de re-
querimientos de información (parte II), El proceso de análisis (parte III), Fundamentos del diseño (parte IV) y
Aseguramiento de calidad e implementación (parte V).
La Parte I (capítulos 1 al 3) hace énfasis en los fundamentos que necesitan conocer los estudiantes sobre lo
que hace un analista; además ofrece una introducción a las tres principales metodologías del ciclo de vida del de-
sarrollo de sistemas (SDLC), las metodologías ágiles y el análisis
orientado a objetos con UML, junto con los motivos y las situaciones
que indican cuándo utilizarlos. La parte I muestra varios sistemas de
información emergentes, incluyendo las tecnologías móviles e inalám-
bricas, y los sistemas empresariales que integran TI y se ajustan en las
organizaciones; cómo determinar si vale la pena comprometerse con
un proyecto de sistemas; la administración de proyectos de comercio
electrónico; y cómo administrar un proyecto de sistemas mediante el
uso de herramientas especiales de software. Se presentan los tres pa-
peles del analista de sistemas como consultor, experto en soporte y
agente de modificación; también se abordan las cuestiones éticas y los
lineamientos profesionales para fungir como consultor de sistemas. Se
incluye material sobre los equipos y las organizaciones virtuales, y
se introduce el concepto de HCI. Se presenta además el concepto del
software de código fuente abierto (OSS). El capítulo 2 indica cómo
empezar a trabajar con una organización, para lo cual se dibujan los diagramas de flujo de datos a nivel de contexto, se
utilizan los modelos de entidad-relación y se desarrollan casos de uso y escenarios de casos de uso. En el capítulo 3
se introduce material extendido sobre la creación de los estatutos del proyecto y se introduce la propuesta de siste-
mas en las primeras etapas del proceso, sin importar qué método de análisis y diseño se haya elegido. También se
incluye una cobertura más extensa sobre la evaluación del software y hardware, y cuándo usar COTS (software
comercial de venta a través de los canales convencionales). Aquí se enseñan varios métodos para pronosticar los
costos y beneficios, lo cual es necesario para el análisis sobre la adquisición de software y hardware. Asimismo,
este capítulo ayuda a los estudiantes a evaluar el software, para lo cual compara las ventajas y desventajas entre la
creación de software personalizado, la compra de software comercial directo de los distribuidores (COTS) o
la subcontratación con un proveedor de servicios de aplicaciones (ASP). También veremos cómo crear la defi-
nición de un problema y presentar una propuesta de sistemas efectiva, en la que se incorporen figuras y gráficos
para comunicarse con los usuarios.
La parte II (capítulos 4 al 6) enfatiza el uso de las metodologías sistemáticas y estructuradas para realizar el
análisis de los requerimientos de información. Esto permite a los analistas asegurarse de tratar con el problema
correcto antes de diseñar el sistema. El capítulo 4 introduce un grupo
de métodos interactivos, incluyendo las entrevistas, el diseño de apli-
caciones conjuntas (JAD) y la construcción de cuestionarios. El capí-
tulo 5 presenta un grupo de métodos discretos para establecer los re-
querimientos de información de los usuarios. Estos métodos incluyen el
muestreo, la investigación de datos duros y los datos de archivo, y la
observación del comportamiento de quienes toman las decisiones y su
entorno físico. El capítulo 6, que trata sobre el modelado ágil y los
prototipos, es innovador en cuanto al tratamiento de los prototipos
como otra técnica de recopilación de datos que permite al analista re-
solver el problema adecuado al hacer que los usuarios se involucren
desde el principio. Los métodos ágiles tienen sus raíces en los prototi-
pos, por lo que este capítulo comienza con la creación de ellos para
proveer un contexto apropiado para su comprensión, y después habla
sobre la metodología ágil. Se presentan los valores y principios, actividades, recursos, prácticas, procesos y herra-
mientas asociadas con las metodologías ágiles. En este capítulo también se incluye material sobre el desarrollo
rápido de aplicaciones (RAD) para la recopilación de los requerimientos de información humana y el diseño de las
interfaces.
PREFACIO xxi
Modificar diagramas
y completar
especificaciones
Desarrollar y
documentar
el sistema
Dibujar diagramas
de caso de uso
Escribir escenarios
de casos de uso
Derivar diagramas
de actividad de los
casos de uso
Desarrollar diagramas
de secuencia
Dibujar diagramas
de estado
Crear diagramas
de clases
Fase de análisis
de sistemas
Fase de diseño
de sistemas
Fase de identificación
de los problemas
Empezar el análisis y
diseño orientado a objetos
Nombre del observador Fecha
Nombre del sistema o proyecto Empresa o ubicación
Nombre o número de programa Versión
Usuario 1 Usuario 2 Usuario 3 Usuario 4
Nombre de usuario
Periodo de observación
Reacciones de los
usuarios
Sugerencias de
los usuarios
Innovaciones
Planes de revisión
Michael Cerveris 1/06/2010
Centro de datos de computación en nube Aquarius Water Filters
Mant. Prev. 1
Andy H. Pam H.
1/06/2010 1/06/2010
Favorable en
general, se
emocionó sobre
el proyecto.
¡Excelente!
Agregar la fecha
en que se realizó
el mantenimiento.
Colocar un número
de formulario en la
parte superior para
referencia. Colocar
la palabra SEMANAL
en el título.
Modificar el
1/08/2010
Revisar con
Andy y Pam.
Formulario de evaluación del prototipowww.xlibros.com

La parte III (capítulos 7 al 10) muestra con detalle el proceso de
análisis. Se basa en las dos partes anteriores para que los estudiantes avan-
cen al tema del análisis de los flujos de datos, así como de las decisiones
estructuradas y semiestructuradas. Provee los detalles sobre cómo utilizar
las técnicas estructuradas para dibujar diagramas de flujo de datos (DFD).
En el capítulo 7 veremos cómo crear diagramas hijos, cómo desarrollar
diagramas de flujo de datos tanto físicos como lógicos y cómo particionar
los diagramas de flujo de datos. El capítulo 8 contiene material acerca del
repositorio de datos y el balanceo vertical de los diagramas de flujo de da-
tos. También veremos los detalles sobre el lenguaje extensible de marcado
(XML) y una demostración acerca del uso de diccionarios de datos para
crear XML. El capítulo 9 incluye material sobre el desarrollo de las especi-
ficaciones de los procesos. Un análisis de las especificaciones tanto físicas
como lógicas de los procesos muestra cómo utilizar las especificaciones de
procesos para el balanceo horizontal. En este capítulo también veremos
cómo crear diagramas de las decisiones estructuradas mediante el lenguaje
inglés estructurado, las tablas y los árboles de decisiones. Además veremos
cómo elegir un método de análisis de decisiones apropiado para analizar las
decisiones estructuradas y crear las especificaciones de los procesos. También se incluye una introducción a las
tecnologías de empuje (push).
La parte III concluye con el capítulo 10 sobre el análisis y diseño de sistemas orientados a objetos. Aquí se
incluye una sección detallada sobre el uso del lenguaje unificado de modelado (UML). También cuenta con una
minuciosa cobertura del modelo de casos de uso, cómo crear el diagrama de modelo de clases con UML, los diagra-
mas de secuencia, la creación de diagramas de generalización/especialización (gen/spec), los escenarios de casos
de uso y los diagramas de actividad. Mediante el uso de varios ejemplos y la sección Oportunidades de consultoría
se demuestra cómo usar una metodología orientada a objetos. Las Oportunidades de consultoría, los diagramas y
los problemas permiten a los estudiantes aprender y utilizar el UML para modelar sistemas desde una perspectiva
orientada a objetos, e identificar las situaciones apropiadas para utilizar una metodología de este tipo. Este capítulo
ayuda a los estudiantes a decidir entre utilizar el SDLC, la metodología ágil o el análisis y diseño de sistemas
orientados a objetos para desarrollar un sistema.
La parte IV (capítulos 11 al 14) trata sobre los fundamentos del di-
seño. Empieza con el diseño de la salida, ya que muchos practicantes tienen
la creencia de que los sistemas están controlados por la salida. Se aborda
con detalle el diseño de formularios basados en Web y se pone especial
atención en relacionar el método de salida con el contenido, el efecto de la
salida sobre los usuarios y cómo diseñar buenos formularios y pantallas. En
el capítulo 11 se comparan las ventajas y las desventajas de la salida, inclu-
yendo pantallas Web, audio, DVD y la salida electrónica como el correo
electrónico y los canales RSS. En este capítulo también se hace un énfasis en
el diseño de un sitio Web para fines de comercio electrónico y se tratan los temas de producción de la salida y el
XML. El capítulo 12 incluye material innovador sobre el diseño de formularios de entrada basados en Web, así
como el diseño de otros tipos de formularios electrónicos. También incluye el diseño de formularios asistido por
computadora.
El capítulo 12 presenta una cobertura detallada sobre el diseño de sitios Web, incluyendo los lineamientos
sobre cuándo deben los diseñadores agregar video, audio y animaciones a los diseños de sitios Web. Veremos los
usos de las tecnologías Web push y pull para los diseños de las salidas. Incluye un estudio detallado de cómo crear
gráficos efectivos para sitios Web corporativos y las formas de diseñar una navegación efectiva en pantalla para los
usuarios de sitios Web.
Incluye una cobertura sobre el diseño de páginas para intranets y extranets, un estudio sobre las restricciones
de integridad en las bases de datos, cómo actúa el usuario con la computadora y cómo diseñar una interfaz apro-
piada. La parte IV también trata sobre la importancia de la retroalimentación de los usuarios. Asimismo veremos
cómo diseñar procedimientos precisos para introducir datos que aprovechan por completo las herramientas compu-
tacionales y humanas para asegurar que se introduzcan datos de calidad.
En el capítulo 13 mostraremos cómo utilizar el diagrama de entidad-relación para determinar las claves de los
registros y proveeremos los lineamientos para el diseño de la relación archivo/base de datos. Los estudiantes apren-
derán acerca de la relevancia del diseño de bases de datos en relación con la utilidad en general del sistema y cómo
utilizar las bases de datos en la realidad.
xxii PREFACIO
método(Parámetro)
retorno
señalAsíncrona()
::Clase Objecto::Clase
Logotipo del sitio Web Artículo de portadaImagen jpeg
Suscripción
de video
Vínculos rápidos Artículos principales Salas de chatAnuncios Vínculo de contacto por email
Fuentes RSS
Anuncios de pancarta
Vínculos a
sub-Webs
Motor de búsquedawww.xlibros.com

El capítulo 14 hace énfasis en la interacción humano-computadora (HCI), especialmente la forma en que se
relaciona con el diseño de interfaces. Aquí se introduce el concepto de HCI y su importancia en el diseño de siste-
mas que se adapten a los individuos y los ayuden a cumplir con sus metas personales y organizacionales mediante
el uso de la tecnología de la información. Se introducen los conceptos sobre capacidad de uso, ajuste, utilidad
percibida y facilidad de uso percibida, al igual que el Modelo de aceptación de tecnología (TAM), de manera que
los estudiantes de sistemas puedan hacerse expertos en incorporar las prácticas de HCI a sus diseños. Asimismo
veremos material relacionado con el diseño de un sistema de navegación en pantalla sencillo para los visitantes de
sitios Web. El capítulo presenta las metodologías innovadoras para realizar búsquedas en Web, resalta la informa-
ción importante sobre el diseño de GUI y provee metodologías innovadoras para diseñar cuadros de diálogo. El
capítulo 14 articula las consideraciones de diseño especializadas para los sitios Web de comercio electrónico.
Introduce el concepto de las aplicaciones Web híbridas (mashups), que se crean al combinar dos o más interfaces
de programación de aplicaciones basadas en Web. Por último, incluye una cobertura detallada para formular con-
sultas, todo dentro del marco de trabajo de HCI.
La parte V (capítulos 15 y 16) concluye el libro. El capítulo 15 se
enfoca en el diseño de procedimientos precisos de introducción de datos e
incluye material sobre la administración de la cadena de suministro a través
del diseño efectivo del comercio electrónico de negocio a negocio (B2B).
El capítulo 16 hace énfasis en el uso de una metodología de calidad total
para mejorar el diseño y el mantenimiento del software. Además incluye
material sobre seguridad de sistemas y firewalls. Los procesos de prueba,
auditoría y mantenimiento de sistemas se describen en el contexto de la
administración de calidad total. Este capítulo ayuda a los estudiantes a com-
prender cómo es que la arquitectura orientada a servicios (SOA) y las nubes
de computadoras están cambiando la naturaleza del diseño de sistemas de
información. Asimismo, los estudiantes aprenderán cómo diseñar progra-
mas de capacitación apropiados para los usuarios del nuevo sistema, cómo
reconocer las diferencias entre las estrategias de conversión físicas y cómo
recomendar la estrategia apropiada a un cliente. El capítulo 16 también
presenta las técnicas para modelar redes, lo cual se puede llevar a cabo mediante herramientas populares tales como
Microsoft Visio.
Se incluye material sobre seguridad y privacidad en relación con el diseño de aplicaciones de comercio elec-
trónico; también veremos información sobre seguridad, en especial firewalls, puertas de enlace (gateways), infra-
estructura de clave pública (PKI), transacciones electrónicas seguras (SET), nivel de sockets seguros (SSL), soft-
ware antivirus, productos para filtrar URL y correo electrónico, y redes virtuales privadas (VPN). Adicionalmente
veremos los temas actuales de interés para los diseñadores de aplicaciones de comercio electrónico, incluyendo el
desarrollo y la publicación de las políticas de privacidad corporativas.
En esta sección también veremos información importante sobre la forma en que el analista puede promover y
después monitorear un sitio Web, que incluye el monitoreo de la actividad Web, la promoción de estos sitios, aná-
lisis de tráfico en la red y análisis de los perfiles de la audiencia para asegurar la efectividad de los nuevos sistemas
de comercio electrónico. Además cubriremos de manera sistemática las técnicas para evaluar el proyecto de siste-
mas de información completo.
Esta octava edición contiene un actualizado Glosario de términos y una lista separada de los Acrónimos
utilizados en el libro y en el campo del análisis y diseño de sistemas.
CARACTERÍSTICAS PEDAGÓGICAS
Cada capítulo de esta edición contiene:
Objetivos de aprendizaje al inicio de cada capítulo.
Resúmenes que enlazan los puntos principales de cada capítulo y proporcionan una excelente fuente de
repaso para los exámenes.
Palabras clave y frases.
Preguntas de revisión.
Problemas.
Proyectos en grupo que ayudan a los estudiantes a trabajar en conjunto en un equipo de sistemas para re-
solver problemas importantes que se resuelven mejor a través de la interacción en un grupo.
Oportunidades de consultoría: ahora con más de 60 mini casos a lo largo del libro.
PREFACIO xxiii
Servicios Web Servicios de
aplicaciones
Servicios de bases
de datos
Computadoras clientewww.xlibros.com

Atractivo Mac: columnas que informan a los estudiantes sobre el software de diseño disponible en la
Mac y el iPhone.
Experiencias de HyperCase.
Episodios del caso de la CPU: partes de un caso continuo esparcidas por todo el libro.
OPORTUNIDADES DE CONSULTORÍA
La octava edición presenta más de 60 oportunidades de consultoría.
Muchas de ellas tratan sobre temas relevantes y emergentes que han
surgido en el campo, incluyendo el diseño de sistemas desde una pers-
pectiva de HCI, aplicaciones de comercio electrónico para la Web, soft-
ware COTS y el uso de UML para modelar sistemas de información
desde una perspectiva orientada a objetos. Las oportunidades de consul-
toría se pueden utilizar para estimular debates en la clase o se pueden
asignar como tareas o preguntas de examen para resolver en casa.
Debido a que no todos los sistemas son proyectos extendidos de dos
o tres años, nuestro libro contiene muchas oportunidades de consultoría
que se pueden resolver con rapidez en 20 o 30 minutos en grupo o por
escrito en forma individual. El objetivo de estos minicasos, que están es-
critos con un toque de humor para alegrar un poco el momento, es que los estudiantes sinteticen lo que han apren-
dido hasta ese punto del curso, que maduren en cuanto a su juicio profesional y ético, y que articulen el razona-
miento que condujo a sus decisiones sobre los sistemas.
EXPERIENCIAS DE HYPERCASE
En cada capítulo se presentan Experiencias de HyperCase®, que plan-
tean desafiantes ejercicios para los estudiantes. En esta octava edición se
incluyen nuevos escenarios, gráficos y problemas para acompañar la
versión 2.8 de HyperCase. Este software cuenta con problemas organi-
zacionales basados en sistemas con tecnología de punta. HyperCase re-
presenta a una organización virtual original que permite a los estudiantes
que acceden a ella sumergirse de inmediato en la vida organizacional.
Los estudiantes entrevistarán personas, observarán los entornos de ofi-
cina, analizarán sus prototipos y revisarán la documentación de sus sis-
temas existentes. HyperCase 2.8 es un software interactivo basado en
Web que presenta a una organización llamada Maple Ridge Engineering
(MRE) en un entorno colorido con gráficos tridimensionales. HyperCase
permite a los profesores abordar la clase sobre el análisis y diseño de
sistemas con apasionante material multimedia. Al observar cuidadosa-
mente la manera en que utilizan el tiempo y administran varios métodos,
los estudiantes utilizan las herramientas de hipertexto de HyperCase en la Web para crear sus propias rutas indivi-
duales por la organización.
Maple Ridge Engineering se basa en las experiencias de consultoría reales de los autores de la versión original
(Raymond Barnes, Richard Baskerville, Julie E. Kendall y Kenneth E. Kendall). Allen Schmidt se unió al proyecto
para la versión 2.0 y ha permanecido en él. Peter Schmidt fue el programador de HTML y Jason Reed creó las
imágenes para la versión Web inicial.
En cada capítulo hay Experiencias de HyperCase recién actualizadas que incluyen asignaturas (e incluso al-
gunas pistas) para ayudar a los estudiantes a resolver los difíciles problemas organizacionales, incluyendo el desa-
rrollo de nuevos sistemas, la fusión de departamentos, la contratación de empleados, la seguridad, el comercio
electrónico y la planificación de recuperación de desastres, todo lo cual pueden encontrar en MRE. HyperCase se
ha probado totalmente en salones de clases y resultó ganador de un premio en la competencia de Instrucción
Innovadora del Instituto de Ciencias de la Decisión (Decision Sciences Institute Innovative Instruction).
EPISODIOS DEL CASO DE LA CPU
Para hacer honor a nuestra creencia de que es importante usar una variedad de metodologías, hemos integrado una
vez más el caso de la Central Pacific University (CPU) en cada capítulo de esta edición. El caso de la CPU utiliza
xxiv PREFACIO
Apellido paterno del paciente Primer nombre Inicial segundo nombre
Estación de inspección Fecha del examen
Número de paciente Número de seguro social
Primer examen Número de reclamación
SECCIÓN DE AUDIOMETRÍA VOCAL Comentarios [
UMBRAL DE RECEPCIÓN DE VOZ
Oído derecho [ ]
Oído izquierdo [ ] Referido por [ ]
DISCR. OÍDO DERECHO. Motivo de referencia
% [ ] Enmascaramiento [ ]
% [ ] Enmascaramiento [ ]
Audiólogo examinador
DISCRIM. OÍDO IZQUIERDO Número de audiólogo examinador
Siguiente solicitante
INFORME DEL EXAMEN AUDIOLÓGICO
CONDUCCIÓN DE AIRE
CONDUCCIÓN ÓSEA
500 1000 2000 4000 6000
Oído derecho
500 1000 2000 4000 6000
Oído izquierdo
500 1000 2000 4000 6000
Oído derecho
500 1000 2000 4000 6000
Oído izquierdowww.xlibros.com

las herramientas Microsoft Access, Microsoft Visio y la popular herramienta
CASE Visible Analyst, de Visible Systems, Inc. para la captura de las pan-
tallas de ejemplo y los ejercicios para los estudiantes.
En el caso de la CPU, los estudiantes recorrerán todas las fases del ciclo
de vida del desarrollo de sistemas. Este caso funcional ofrece a los estudian-
tes la oportunidad de resolver problemas por su cuenta, mediante el uso de
varias herramientas y datos que los usuarios del libro pueden descargar del
sitio Web complementario y que incluyen ejercicios de Microsoft Visio,
Microsoft Access y Visible Analyst relacionados específicamente con cada
capítulo del libro. Además, hay ejercicios parcialmente resueltos, disponi-
bles a través del sitio Web en forma archivos de Microsoft Access, para que
los estudiantes los utilicen. El caso de la CPU se ha probado completamente
en salones de clases en todo el mundo con una amplia variedad de estudian-
tes y durante varios periodos académicos. El caso es tan detallado, riguroso
y completo, que se podría utilizar como un proyecto independiente de aná-
lisis y diseño de sistemas durante uno o dos periodos académicos, O como
un método para enseñar sobre el uso de las herramientas CASE junto con la
asignatura de un proyecto real durante uno o dos periodos académicos fuera del salón de clases.
SOPORTE WEB EXPANDIDO (EN INGLÉS)
La octava edición de Análisis y diseño de sistemas de Kendall y Kendall
cuenta con soporte basado en Web para ofrecer técnicas pedagógicas sóli-
das e interesantes en el campo de los sistemas de información.
El sitio Web se encuentra en www.pearsoneducacion.net /kendall y
contiene muchas herramientas de aprendizaje y apoyo imprescindi-
bles, para que los debates en clase siempre sean emocionantes.
HyperCase 2.8 es un juego interactivo de una organización virtual
que ha obtenido varios premios. Se anima a los estudiantes a entre-
vistar personas en la organización, analizar problemas, modificar los
diagramas de flujo y los diccionarios de datos, reaccionar a los proto-
tipos y diseñar nuevas entradas y salidas. Ahora HyperCase cuenta
con una inconfundible apariencia en 3-D.
Ejercicios para los estudiantes con base en el caso continuo de la
CPU, con ejemplos y problemas parcialmente resueltos almacenados
en archivos de Microsoft Access y Visible Analyst, para que los estu-
diantes desarrollen un sistema de administración computacional ba-
sado en Web.
SOPORTE WEB COMPLEMENTARIO EXTENDIDO
PARA INSTRUCTORES
En la página de este libro www.pearsoenducacion.net/kendall hay recursos de soporte extendido para los instruc-
tores que usen esta edición (en inglés):
Un conjunto completo de diapositivas de presentaciones de PowerPoint para emplearlas en conferen-
cias.
Biblioteca de imágenes (Image Library), una colección organizada por capítulo.
Manual para el instructor con respuestas a los problemas, soluciones a los casos y sugerencias para
abordar el tema en cuestión.
Test Item File Un archivo de elemento de prueba en Microsoft Word y TestGen con conversiones listas
para WebCT y Blackboard.
Soluciones a los ejercicios para los estudiantes basadas en el caso continuo de la CPU, con soluciones
y ejemplos almacenados en archivos de Visual Analyst y de Microsoft Access.
Para mayor información, contacte al Representante de Pearson en su zona.
PREFACIO xxvwww.xlibros.com

www.xlibros.com

AGRADECIMIENTOS
Durante la redacción de esta octava edición de Análisis y diseño de sistemas ocurrieron cambios rápidos y consi-
derables en la tecnología de la información. Nos deleita saber que esta edición se publica en el momento adecuado
para reflejar muchos de estos avances en el desarrollo de sistemas.
Uno de los principales cambios es el surgimiento de tres metodologías principales para el desarrollo: SDLC,
metodologías ágiles y el análisis y diseño de sistemas orientado a objetos. La presente obra muestra dónde y en qué
situaciones le puede servir cada una de estas metodologías a usted, como analista de sistemas.
Otro de los grandes cambios es el rápido aumento en el uso de la Web como plataforma para sistemas de in-
formación. La arquitectura orientada a servicios y la computación en nube están cambiando la forma en que el
analista debe abordar el diseño de soluciones de sistemas. Además de la Web, los analistas se ven presionados a
diseñar para un amplio espectro de tecnologías de información emergentes, como las inalámbrica y móvil, los
sistemas empresariales y los contextos virtuales tales como equipos y organizaciones virtuales.
Otro de los cambios importantes reflejados en esta edición es la habilidad de los usuarios para personalizar sus
escritorios, espacios de trabajo y páginas Web, e incluso de alterar los diseños profesionales de los analistas de
sistemas. A diferencia de los usuarios, los analistas ven todo el panorama y siempre deben estar conscientes de los
impactos organizacionales que se producen al cambiar los sistemas.
A través de este libro usted aprenderá y aplicará numerosas técnicas, métodos, herramientas y metodologías.
Pero llegado el momento de interpretar lo que ocurre en la organización y desarrollar sistemas de información re-
presentativos con base en las reglas que usted aplique en su análisis, lo que aprendió deberá combinarse con la
creatividad para producir un sistema que puede ser en cierto modo una sorpresa: es estructurado pero intuitivo;
basado en multiniveles y complejo para estar en armonía con el carácter de la organización, y además debe reflejar
su personalidad como analista de sistemas y ser humano.
Nuestros estudiantes merecen crédito por esta nueva edición, ya que brindaron retroalimentación y sugerencias
para mejorar, además de pedir una cobertura más detallada sobre ciertos temas. Los estudiantes nos dijeron que
pusieron rápidamente en uso el nuevo material sobre el análisis y diseño de sistemas orientados a objetos, así como
el de modelado ágil. Su afán por enseñarnos nuevas cosas mantuvo la frescura de este libro. Queremos agradecer
a nuestro coautor Allen Schmidt, quien una vez más trabajó con nosotros en los Episodios del caso de la CPU y en
HyperCase 2.8, por todo su gran esfuerzo, dedicación y humor durante el tiempo que estuvimos colaborando con
él. Es una persona maravillosa. También ofrecemos nuestro agradecimiento a Peter Schmidt y Jason Reed por
mejorar el software HyperCase anterior. Y queremos agradecer a los otros dos autores originales de HyperCase,
Richard Baskerville y Raymond Barnes por su enorme contribución.
Damos la gracias al equipo de producción de la octava edición, en especial a nuestro director ejecutivo Bob
Horan, cuya sabiduría y tranquilidad siempre brindan inspiración. También agradecemos a Kelly Loftus, nuestra
extremadamente habilidosa editora asistente, por su ecuánime competencia y su optimismo para mantener el pro-
yecto en constante avance. Ana Jankowsi, nuestra editora de producción, también merece una mención especial por
ayudarnos a convertir este proyecto en una revisión sólida, completa y precisa. Su ayuda y entusiasmo facilitaron
el proceso de completar el proyecto sin problemas y a tiempo.
También queremos agradecer el estímulo y el apoyo de toda la comunidad Rutgers, incluyendo a nuestro mi-
nistro Wendell Prittchett, nuestros colegas en la Escuela de Negocios de Camden y en todo Rutgers, a nuestro
personal y al Consejo de Administración. Todos han mostrado mucho entusiasmo sobre esta edición, y sobre las
diversas traducciones de este libro disponibles en español, chino e indonesio.
xxviiwww.xlibros.com

Todos los revisores de la octava edición merecen también nuestro agradecimiento. Sus considerados comen-
tarios y sugerencias ayudaron a fortalecer el libro. Ellos son:
Stephen T. Brower, Raritan Valley Community College
Robert F. Cope III, Southeastern Lousiana University
Junhua Ding, East Carolina University
Jon Gant, University of Illinois
Cliff Layton, Rogers State University
Keng Siau, University of Nebraska-Lincoln
Muchos de nuestros colegas y amigos nos alentaron al momento de escribir este libro. Queremos agradecer sus
comentarios sobre nuestro trabajo a Ayman Abu Hamdieh, Macedonio Alanis, Michel Avital, los Ciupek, Charles J.
Coleman, Roger T. Danforth, Gordon Davis, EgoPo, Paul Gray, Nancy V. Gulick, Andy y Pam Hamingson, Blake
Ives, Richard Kalina, Carol Latta, Ken y Jane Laudon, Richard Levao, Joel y Bobbie Porter, Caryn Schmidt, Marc y
Jill Schniederjans, Gabriel Shanks, Detmar W. Straub, Jr., los Vargo, Merrill Warkentin, Jeff y Bonnie Weil, Ping
Zhang, a todos nuestros amigos y colegas en la Asociación para Sistemas de Información, el Instituto de Ciencias de
la Decisión, el Grupo de trabajo 8.2 del IFIP y a todos aquellos involucrados en el Proyecto PhD (financiado por la
Fundación KPMG), que atiende a estudiantes de minorías en doctorados en sistemas de información.
Agradecemos de corazón a la memoria de Julia A. Kendall y a la memoria de Edward J. Kendall. Su convicción
de que el amor, las metas y el trabajo duro son una combinación invencible sigue influyendo en todos nuestros
esfuerzos.
xxviii AGRADECIMIENTOS
Julie y Ken Kendall agradecen personalmente a Shrek (Brian d’Arcy James) y a todos nuestros queridos
amigos en el teatro y las artes escénicas.www.xlibros.com

1
C A P Í T U L O 1
Sistemas, roles y
metodologías de desarrollo
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Recordar los tipos básicos de sistemas de computación que un analista debe conocer.
2. Comprender la forma en que los usuarios de las nuevas tecnologías pueden modificar
la dinámica de un sistema.
3. Conocer los distintos roles de un analista de sistemas.
4. Comprender los fundamentos de tres metodologías de diseño: SDL, la metodología ágil
y el análisis y diseño de sistemas orientado a objetos.
5. Aprender sobre las herramientas CASE y cómo pueden ayudar a un analista de
sistemas.
Durante mucho tiempo, las organizaciones han reconocido la importancia
de administrar recursos clave como las personas y la materia prima. Actual-
mente, la información ha encontrado su lugar apropiado como recurso
clave. Los responsables de la toma de decisiones por fin comprenden que
la información no es sólo un producto derivado de las operaciones comer-
ciales, sino que además provee impulso a las empresas y puede constituir el factor decisivo para
determinar el éxito o el fracaso de un negocio.
Para maximizar la utilidad de la información, una empresa debe administrarla en forma
apropiada, de la misma manera en que administra los demás recursos. Los administradores
necesitan comprender que hay costos asociados con la producción, distribución, seguridad, el
almacenamiento y la recuperación de toda información. Aunque la información está a nuestro
alrededor, no es gratuita y no debemos dar por hecho su uso estratégico para poner a una
empresa en una posición competitiva.
El hecho de que las computadoras se puedan conectar de manera rápida y sencilla a una
red, aunado a la capacidad de acceder a Internet y Web, ha creado una explosión de informa-
ción en la sociedad en general, y en los negocios en particular. El proceso de administrar la
información generada por computadora difiere de manera considerable del proceso de mane-
jar los datos producidos en forma manual; por lo general debemos administrar una mayor
cantidad de información computacional. Los costos de administración y mantenimiento pue-
den aumentar a ritmos alarmantes, y a menudo los usuarios consideran este tipo de informa-
ción con menos escepticismo que la que se obtiene de otras fuentes. En este capítulo
examinaremos los fundamentos de distintos tipos de sistemas de información, los diversos
roles de los analistas de sistemas, las fases en el ciclo de vida del desarrollo de sistemas (SDLC)
y la forma en que se relacionan con los factores de Interacción humano-computadora (HCI),
además de una introducción a las herramientas de Ingeniería de Software Asistida por Compu-
tadora (CASE).
P A R T E I
Fundamentos del
análisis de sistemaswww.xlibros.com

2 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
TIPOS DE SISTEMAS
Los sistemas de información se desarrollan para distintos fines, dependiendo de las necesidades de los usuarios
humanos y la empresa. Los sistemas de procesamiento de transacciones (TPS) funcionan en el nivel operacional
de la organización; los sistemas de automatización de oficinas (OAS) y los sistemas de trabajo de conocimiento
(KWS) brindan soporte para el trabajo a nivel del conocimiento. Entre los sistemas de nivel superior se encuen-
tran los sistemas de información administrativa (MIS) y los sistemas de soporte de decisiones (DSS)∗. Los siste-
mas expertos aplican la experiencia de los encargados de tomar decisiones para resolver problemas específicos y
estructurados. En el nivel estratégico de la administración se encuentran los sistemas de soporte para ejecutivos
(ESS). Los sistemas de soporte de decisiones en grupo (GDSS) y los sistemas de trabajo colaborativo asistido
por computadora (CSCWS), que se describen en forma más general, ayudan en el proceso de toma de decisiones,
a nivel de grupo, de la variedad semiestructurada o no estructurada.
En la figura 1.1 se muestra la variedad de sistemas de información que pueden desarrollar los analistas.
Observe que la figura presenta estos sistemas de arriba hacia abajo, indicando que el nivel operacional de la or-
ganización (el más bajo) cuenta con apoyo (soporte) de los sistemas TPS, mientras que el nivel estratégico de
decisiones semiestructuradas y no estructuradas (el más alto) cuenta con soporte de los sistemas ESS, GDSS
y CSCWS en la parte superior. En este libro utilizamos los términos sistemas de información administrativa,
sistemas de información (IS), sistemas de información computarizados y sistemas de información de negocios
computarizados para indicar los mismos sistemas de información computarizados que ofrecen soporte para el
rango más amplio de interacciones de los usuarios con las tecnologías y actividades comerciales por medio de la
información que producen en contextos organizacionales.
Sistemas de procesamiento de transacciones
Los sistemas de procesamiento de transacciones (TPS) son sistemas de información computarizados que se de-
sarrollaron para procesar grandes cantidades de información para las transacciones de negocios rutinarias, como
nóminas e inventario. Un TPS elimina el tedio de las transacciones operacionales necesarias y reduce el tiempo
que se requería para realizarlas en forma manual, aunque la mayoría de las personas aún deben introducir los
datos en forma manual en los sistemas computarizados.
Los sistemas de procesamiento de transacciones son sistemas que atraviesan límites y permiten que la organi-
zación interactúe con los entornos externos. Como los administradores analizan los datos generados por el TPS para
obtener información actualizada sobre lo que ocurre en sus empresas, es imprescindible que estos sistemas funcionen
sin problemas ni interrupciones para sustentar las operaciones diarias de estas compañías.
Sistemas de automatización de oficinas y sistemas de trabajo de conocimiento
En el nivel de conocimiento de la organización hay dos clases de sistemas. Los sistemas de automatización de
oficinas (OAS) brindan apoyo a las personas que trabajan con datos no para crear conocimiento sino para anali-
ESS
GDSS
CSCWS
Sistemas expertos
Sistemas de soporte de decisiones
Sistemas de información administrativa
Sistemas de trabajo de conocimiento
Sistemas de automatización de oficinas
Sistemas de procesamiento de transacciones
FIGURA 1.1
Un analista de sistemas puede
involucrarse con cualquiera o con
todos estos sistemas.
* Esta traducción es la más aceptada por la mayoría de los académicos, aunque una mejor traducción de estas siglas sería: Sistemas de apoyo a la
toma de decisiones, y sistemas de apoyo a la toma de decisiones en grupo, para las siglas GDSS.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 3
zar la información y transformar los datos o manipularlos de cierta forma antes de compartirlos o diseminarlos de
manera formal a través de la organización y, algunas veces, más allá. Los aspectos más conocidos de los sistemas
OAS son el procesamiento de palabras, las hojas de cálculo, el diseño gráfico por computadora, la planificación
electrónica y la comunicación a través de correo de voz, correo electrónico (e-mail) y teleconferencias.
Los sistemas de trabajo de conocimiento (KWS) brindan apoyo a profesionales como científicos, ingenieros y
médicos, ayudándoles a crear conocimiento (a menudo en equipos) y a integrarlo a su organización o la sociedad.
Sistemas de información administrativa
Los sistemas de información administrativa (MIS) no sustituyen a los sistemas de procesamiento de transaccio-
nes; más bien, todos los sistemas MIS incluyen el procesamiento de transacciones. Los MIS son sistemas de
información computarizados que funcionan debido a la decidida interacción entre las personas y las computado-
ras. Al requerir que las personas, el software y el hardware funcionen en concierto, los sistemas de información
administrativa brindan soporte a los usuarios para realizar un espectro más amplio de tareas organizacionales que
los sistemas de procesamiento de transacciones, incluyendo los procesos de análisis y toma de decisiones.
Para acceder a la información, los usuarios del sistema de información administrativa comparten una base
de datos común; ésta almacena tanto los datos como los modelos que permiten al usuario interactuar con ellos,
interpretarlos y aplicarlos. Los sistemas de información administrativa producen información que se utiliza en
el proceso de toma de decisiones. También pueden ayudar a integrar algunas de las funciones de información
compu tarizadas de una empresa.
Sistemas de soporte de decisiones
Los sistemas de soporte de decisiones (DSS, o sistemas de apoyo a la toma de decisiones) pertenecen a una clase
superior de sistemas de información computarizados. Los sistemas DSS son similares al sistema de información
administrativa tradicional debido a que ambos dependen de una base de datos como fuente de datos. La diferen-
cia estriba en que el sistema de soporte de decisiones está más enfocado a brindar respaldo a la toma de decisio-
nes en todas sus fases, aunque la decisión misma aún corresponde de manera exclusiva al usuario. Los sistemas
de soporte de decisiones se ajustan más a la persona o el grupo usuario que un sistema de información adminis-
trativa tradicional. También se describen a veces como sistemas enfocados en la inteligencia de negocios.
Inteligencia artificial y sistemas expertos
La inteligencia artificial (AI) puede ser considerada como el campo dominante de los sistemas expertos. La
idea general de la AI ha sido desarrollar equipos que se comporten de manera inteligente. Dos ramas de inves-
tigación de la AI son 1) la comprensión del lenguaje natural y (2) el análisis de la habilidad para razonar un
problema y llegar a una conclusión lógica. Los sistemas expertos utilizan las metodologías de razonamiento de
la AI para resolver los problemas que los usuarios de negocios (y otros tipos de usuarios) les presentan.
Los sistemas expertos son una clase muy especial de sistema de información que ha demostrado su utilidad co-
mercial gracias a la disponibilidad extendida de hardware y software como las computadoras personales (PC) y las
interfaces de sistemas expertos. Un sistema experto (también conocido como sistema basado en el conocimiento) cap-
tura y utiliza en forma efectiva el conocimiento de uno o varios expertos humanos para resolver un problema especí-
fico al que una organización se enfrenta. Cabe mencionar que a diferencia de los sistemas DSS, que en última instancia
dejan la decisión a la persona encargada de la toma de decisiones, un sistema experto selecciona la mejor solución para
un problema o una clase específica de problemas.
Los componentes básicos de un sistema experto son la base de conocimiento, un motor de inferencia que
conecta al usuario con el sistema mediante el proceso de consultas en lenguajes —como el lenguaje de consulta
estructurado (SQL) —, y la interfaz de usuario. Las personas conocidas como ingenieros del conocimiento cap-
turan la experiencia de los expertos, crean un sistema computacional que incluye este conocimiento y después lo
implementan.
Sistemas de soporte de decisiones en grupo
y sistemas de trabajo colaborativo asistido por computadora
Las organizaciones confían cada vez más en los grupos o equipos para tomar decisiones en conjunto. Cuando
los grupos toman decisiones semiestructuradas o no estructuradas, un sistema de soporte de decisiones en grupo
(GDSS, o sistema de apoyo a la toma de decisiones en grupo) puede ofrecer una solución. Estos sistemas, que se
utilizan en cuartos especiales equipados con varias configuraciones, permiten a los miembros de los grupos inte-
ractuar con el soporte electrónico (a menudo en la forma de software especializado) y un facilitador de grupo es-
pecial. El objetivo de los sistemas de soporte de decisiones en grupo es lograr que un grupo resuelva un problema
con la ayuda de varios apoyos como encuestas, cuestionarios, lluvia de ideas y creación de escenarios. Se puede
diseñar software GDSS para minimizar los comportamientos de grupo negativos típicos como la escasez de parti-
cipación por temor a las represalias por expresar un punto de vista impopular o polémico, la dominación por partewww.xlibros.com

4 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
de los miembros del grupo con facilidad de palabra y la toma de decisiones mediante el “pensamiento grupal”.
Algunas veces los sistemas GDSS se consideran bajo el término más general de sistemas de trabajo colaborativo
asistido por computadora (CSCWS), que podría incluir el soporte de software conocido como groupware para
colaborar en equipo mediante computadoras conectadas en red. Los sistemas de soporte de decisiones en grupo
también se pueden utilizar en un ambiente virtual.
Sistemas de soporte para ejecutivos
Cuando los ejecutivos fijan su atención en la computadora, a menudo buscan obtener ayuda para tomar deci-
siones en el nivel estratégico. Los sistemas de soporte para ejecutivos (ESS, sistemas de apoyo para ejecutivos)
ayudan a los ejecutivos a organizar sus interacciones con el entorno externo ofreciendo tecnologías de gráficos
y comunicaciones en sitios accesibles como salas de juntas u oficinas corporativas personales. Aunque los sis-
temas ESS se basan en la información que generan los sistemas TPS y MIS, ayudan a sus usuarios a enfrentar
los problemas relacionados con decisiones no estructuradas inespecíficas de una aplicación, para lo cual crean
un entorno que les ayude a pensar sobre los problemas estratégicos de una manera informada. Los sistemas ESS
extienden las capacidades de los ejecutivos y les ofrecen soporte para que puedan entender mejor sus entornos.
INTEGRACIÓN DE LAS TECNOLOGÍAS EN SISTEMAS
A medida que los usuarios adoptan nuevas tecnologías, parte del trabajo del analista de sistemas consiste en in-
tegrar los sistemas tradicionales con los nuevos para asegurar un contexto útil, como se muestra en la figura 1.2.
En esta sección veremos algunas de las nuevas tecnologías de información que los analistas de sistemas utilizan
a medida que las personas trabajan para integrar sus aplicaciones de comercio electrónico en sus negocios tradi-
cionales, o a medida que inician negocios electrónicos completamente nuevos.
Las aplicaciones de comercio electrónico y los sistemas Web
A muchos de los sistemas que veremos en este libro se les puede agregar una mayor funcionalidad si se hacen mi-
grar a la World Wide Web o si se conciben e implementan originalmente como tecnologías basadas en Web. Hay
muchos beneficios relacionados con el proceso de montar o mejorar una aplicación en Web:
1. Aumenta el número de usuarios que se enteran de la disponibilidad de un servicio, producto, industria,
persona o grupo.
2. Los usuarios tiene la posibilidad de acceder las 24 horas del día.
ESS
GDSS
CSCWS
Sistemas expertos
Sistemas de soporte de decisiones
Sistemas de información administrativa
Sistemas de trabajo de conocimiento
Sistemas de automatización de oficinas
Sistemas de procesamiento de transacciones
CSCWS
ones
administrativa
Sistemas de trabajo de
Sistemas de a
e transaccionesS i s t e m a s i n a l á m
b r i c
o
s
S i s t e m a s e m
p
r
e
s
a
r
i
a
l
e
s
Sistemas Web y de comercio electrónico
FIGURA 1.2
Los analistas de sistemas necesitan
estar conscientes de que al integrar
tecnologías se ven afectados todos
los tipos de usuarios y sistemas.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 5
3. Se puede mejorar la utilidad y capacidad de uso del diseño de la interfaz.
4. Se puede expandir un sistema globalmente en vez de permanecer en el entorno local, con lo cual se puede
establecer contacto con personas en ubicaciones remotas sin preocuparse por la zona horaria en la que se
encuentren.
Sistemas empresariales
Muchas organizaciones preveen beneficios potenciales derivados de la integración de diversos sistemas de
información existentes en distintos niveles administrativos y dentro de diferentes funciones. Algunos autores
describen la integración como arquitectura orientada a servicios (SOA), la cual existe en capas. Los sistemas
empresariales conformarían la capa superior. Estos sistemas, también conocidos como sistemas de planificación
de recursos empresariales (ERP), están diseñados para llevar a cabo esta integración. Para establecer un ERP se
requiere de un enorme compromiso y cambios en la organización. A menudo, los analistas de sistemas actúan
como consultores para los proyectos de ERP que utilizan software propietario. Dentro del software ERP popular
están los sistemas de SAP y Oracle. Algunos de estos paquetes están orientados hacia el proceso de migrar las
empresas a la Web. Por lo general, los analistas y algunos usuarios requieren capacitación, soporte y manteni-
miento por parte del distribuidor para diseñar, instalar, mantener, actualizar y utilizar de manera apropiada un
paquete ERP específico.
Sistemas para dispositivos inalámbricos y móviles
Se ha pedido a los analistas diseñar una amplia variedad de sistemas y aplicaciones para usuarios aventureros,
como las orientadas a dispositivos inalámbricos y móviles como el iPhone y el iPod de Apple o la BlackBerry.
Adicionalmente, algunos de ellos tal vez se enfrenten al reto de diseñar redes de comunicaciones estándar o ina-
lámbricas que integren voz, video, mensajería de texto y correo electrónico a las intranets de una organización o
a las extranets industriales. El comercio electrónico inalámbrico se conoce como m-Commerce o mCommerce
(comercio móvil).
Tal vez a usted le pidan diseñar sistemas de redes inalámbricas de área local (WLAN); redes de fidelidad
inalámbrica, conocidas como Wi-Fi o redes personales inalámbricas que reúnan muchos tipos de dispositivos
bajo el estándar Bluetooth. En configuraciones más avanzadas, tal vez los analistas tengan que diseñar agentes
inteligentes: software capaz de aprender progresivamente las preferencias de los usuarios para posteriormente
brindarles ayuda basada en el conocimiento adquirido. Por ejemplo, mediante el uso de la tecnología pull, un
agente inteligente puede buscar en la Web historias de interés para el usuario después de haber observado sus
patrones de comportamiento a través del tiempo, y realizar búsquedas en la Web sin tener que estar solicitándole
información en forma continua.
Software de código fuente abierto
El software de código fuente abierto (OSS) es una alternativa al desarrollo de software tradicional, en donde el
código propietario se oculta a los usuarios. Con el OSS, los usuarios y programadores pueden estudiar, com-
partir y modificar el código o las instrucciones de computadora. Las reglas de esta comunidad incluyen la idea
de que cualquier modificación a los programas se debe compartir con todas las personas en el proyecto.
El desarrollo de OSS constituye toda una filosofía y no sólo el proceso de crear software. A menudo, las
personas involucradas en comunidades de OSS lo ven como una forma de ayudar a que las sociedades cam-
bien. Algunos de los proyectos de código fuente abierto más conocidos son el servidor Web Apache, el nave-
gador Mozilla Firefox y Linux, un sistema operativo de código fuente abierto similar a Unix.
No obstante, sería simplista pensar en el OSS como un movimiento monolítico, además de que esto no
ayuda en nada a revelar qué tipo de usuarios o analistas están desarrollando proyectos de OSS y en qué se ba-
san. Para ayudarnos a comprender el movimiento de software libre, algunos investigadores recientemente ca-
tegorizaron las comunidades de software libre en cuatro tipos: ad hoc, estandarizado, organizado y comercial,
además de contar con seis distintas dimensiones: estructura general, entorno, objetivos, métodos, comunidad
de usuarios y licencias. Algunos investigadores argumentan que el OSS está en una encrucijada y que los gru-
pos de OSS comercial y comunitario necesitan comprender dónde convergen y dónde puede haber conflictos
potenciales.
El desarrollo de software de código fuente abierto es útil para muchas aplicaciones que se ejecutan en di-
versas plataformas, incluyendo dispositivos móviles y equipos de comunicación. Su empleo puede contribuir
a acelerar el proceso de estandarización de comunicaciones entre dispositivos. El uso extendido de OSS puede
ayudar a aliviar la severa escasez de programadores, al poner las herramientas de programación en manos
de estudiantes de países en desarrollo en menos tiempo del que se requeriría si estuvieran limitados al uso de
paquetes propietarios, y puede ayudar a resolver grandes problemas mediante una colaboración intensa y ex-
tensa.www.xlibros.com

6 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
NECESIDAD DEL ANÁLISIS Y DISEÑO DE SISTEMAS
El análisis y diseño de sistemas que los analistas de sistemas llevan a cabo busca comprender qué necesitan
los humanos para analizar la entrada o el flujo de datos de manera sistemática, procesar o transformar los
datos, almacenarlos y producir información en el contexto de una organización específica. Mediante un
análisis detallado, los analistas buscan identificar y resolver los problemas correctos. Además, el análisis y
diseño de sistemas se utiliza para analizar, diseñar e implementar las mejoras en el apoyo para los usuarios
y las funciones de negocios que se puedan llevar a cabo mediante el uso de sistemas de información compu-
tarizados.
Si un sistema se instala sin una planificación apropiada, a menudo los usuarios quedan muy insatisfechos y
dejan de usar el sistema. El análisis y diseño añade estructura a los sistemas, y constituye una actividad costosa
que de otra manera se realizaría al azar. Se puede considerar como una serie de procesos que se llevan a cabo en
forma sistemática para mejorar una empresa mediante el uso de sistemas de información computarizados. El aná-
lisis y diseño de sistemas implica trabajar con los usuarios actuales y eventuales de los sistemas de información
para ofrecerles soporte en su empleo de las tecnologías en un entorno organizacional.
La participación del usuario en el proyecto de sistemas es imprescindible para el desarrollo exitoso de los
sistemas de información computarizados. Los analistas de sistemas, cuyos roles en la organización analizaremos
a continuación, son el otro componente esencial para desarrollar sistemas de información útiles.
Los usuarios avanzan al primer plano a medida que los equipos de desarrollo de software se internacionali-
zan más en cuanto a su composición. Esto significa que hay más énfasis en trabajar con los usuarios de software;
en realizar un análisis de su empresa, sus problemas y objetivos; y en comunicar el análisis y diseño del sistema
planificado a todos los involucrados.
Las nuevas tecnologías también impulsan la necesidad del análisis de sistemas. Ajax (JavaScript asíncrono
y XML) no es un nuevo lenguaje de programación, sino una técnica que utiliza los lenguajes existentes para ha-
cer que las páginas Web funcionen en forma más parecida a un programa de aplicación de escritorio tradicional.
Los analistas se enfrentarán a la tarea de crear y rediseñar páginas Web que utilicen tecnologías Ajax. Los nue-
vos lenguajes de programación, como el marco de trabajo Web de código fuente abierto conocido como Ruby
on Rails, una combinación entre lenguaje de programación y generador de código para crear aplicaciones Web,
requerirá de más análisis.
ROLES DEL ANALISTA DE SISTEMAS
El analista de sistemas evalúa en forma sistemática cómo interactúan los usuarios con la tecnología y cómo
operan las empresas, para lo cual examina los procesos de entrada/salida de los datos y la producción de
información con la intención de mejorar los procesos organizacionales. Muchas mejoras implican un mejor
soporte de las tareas de trabajo de los usuarios y las funciones empresariales mediante el uso de sistemas de
información computarizados. Esta definición enfatiza el uso de una metodología sistemática para analizar
(y potencialmente mejorar) lo que ocurre en el contexto específico que los usuarios experimentan y las empre-
sas crean.
Nuestra definición de un analista de sistemas es necesariamente amplia. El analista debe ser capaz de traba-
jar con personas de todo tipo y tener experiencia en cuanto al trabajo con computadoras. El analista desempeña
muchos roles y algunas veces tiene que lidiar con varios al mismo tiempo. Los tres principales roles del analista
de sistemas son como consultor, experto de soporte y agente de cambios.
El analista de sistemas como consultor
Con frecuencia el analista de sistemas actúa como consultor de sistemas para las personas y sus empresas y, por
ende, pueden llegar a contratarlo específicamente para lidiar con las cuestiones relacionadas con los sistemas
de información dentro de la empresa. Dicha contratación puede ser una ventaja, ya que los consultores externos
pueden proveer una perspectiva fresca de la cual carezcan otras personas en la organización. También implica
que los analistas externos están en desventaja, ya que alguien de fuera nunca podrá conocer la verdadera cultura
organizacional. Como consultor externo, usted dependerá en gran parte de los métodos sistemáticos que el libro
describe para analizar y diseñar sistemas de información apropiados para los usuarios que trabajan en una em-
presa en particular. Además se basará en los usuarios de los sistemas de información para que le ayuden a com-
prender la cultura organizacional desde los puntos de vista de los demás.
El analista de sistemas como experto de soporte
Como empleado de una empresa, tal vez le toque desempeñarse como experto en soporte en algún puesto de
sistemas. En este rol, el analista se basa en su experiencia profesional sobre hardware y software y su uso en loswww.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 7
O P O R T U N I D A D D E C O N S U L T O R Í A 1 . 1
Contratación saludable: se solicita ayuda para el comercio electrónico
“Le agradará saber que presionamos mucho a la gerencia para
contratar un nuevo analista de sistemas especializado en el desarro-
llo de comercio electrónico”, dice Al Falfa, analista de sistemas de
la cadena internacional Marathon Vitamin Shops, con múltiples
puntos de venta, quien se reunirá con su extenso equipo de analistas
de sistemas para decidir sobre las cualidades que deberá poseer el
nuevo miembro de su equipo. Al continúa: “De hecho, les emocionó
tanto la posibilidad de que nuestro equipo ayude a migrar a Mara-
thon a una estrategia de comercio electrónico que dijeron que debe-
ríamos empezar a buscar ahora y no esperar hasta otoño”.
Ginger Rute, una de las analistas, asiente diciendo: “La de-
manda de desarrolladores de sitios Web aún sobrepasa a la oferta.
Debemos movernos con rapidez. Creo que el nuevo miembro de
nuestro equipo debe tener experiencia en modelado de sistemas,
JavaScript, C++ y Rational Rose, y debe estar familiarizado con
Ajax, entre otras cosas”.
Al mira sorprendido la extensa lista de habilidades de Ginger
y luego responde: “Bueno, sin duda podríamos basarnos en eso.
Pero también me gustaría una persona con conocimientos de nego-
cios. La mayoría de los recién egresados tienen sólidas habilidades
de programación, pero también deben saber sobre contabilidad,
inventarios y distribución de bienes y servicios”.
Vita Ming, la analista más reciente del grupo, finalmente
participa en la discusión: “Una de las razones por las que elegí
trabajar con ustedes es que sentí que nos llevaríamos muy bien.
Como tenía otras oportunidades, analicé con mucho cuidado la
atmósfera de aquí. Hasta donde he visto, somos un grupo amigable.
Debemos asegurarnos de contratar a alguien con buena personali-
dad y que se acople bien a nosotros”.
Al asiente y continúa: “Vita tiene razón. El nuevo miembro
debe ser capaz de comunicarse bien tanto con nosotros como con los
clientes de la empresa. Siempre nos estamos comunicando de una
forma u otra, por medio de presentaciones formales, dibujando
diagramas o entrevistando usuarios; si comprenden el proceso de
toma de decisiones, el trabajo será más sencillo. Asimismo, Mara-
thon está interesada en integrar el comercio electrónico en todas las
actividades comerciales. Necesitamos alguien que por lo menos
tenga una noción de la importancia estratégica de la Web. El diseño
de páginas es una parte muy pequeña de ello”.
Ginger interviene de nuevo con una dosis saludable de sen-
tido práctico y dice: “Dejemos eso a la administración. Yo sigo
pensando que el nuevo miembro debe ser un buen programador”.
Después delibera en voz alta: “Me pregunto, ¿qué tan importante
será el UML?”.
Después de escuchar pacientemente la lista de deseos de todos
los demás, Carl Siem, uno de los analistas en jefe habla bromeando:
“¡Mejor deberíamos averiguar si Supermán está disponible!”.
Mientras todos en el grupo comparten risas, Al ve una oportu-
nidad de intentar consenso y dice: “Ya escuchamos varias cualida-
des. Ahora hagamos, cada uno de nosotros, una lista de las
cualidades que personalmente creemos deba poseer la nueva per-
sona encargada del desarrollo de comercio electrónico. Comparti-
remos las listas y seguiremos discutiendo hasta que podamos
describir a la persona con el detalle suficiente como para enviar la
descripción al grupo de recursos humanos para que la procesen.”
¿Qué cualidades debería estar buscando el equipo al contra-
tar al nuevo miembro del equipo de desarrollo de comercio elec-
trónico? ¿Es más importante conocer lenguajes específicos o tener
la aptitud de aprender a usar lenguajes y paquetes de software con
rapidez? ¿Qué tan importante es que la persona a contratar tenga
ciertos conocimientos básicos de negocios? ¿Deben todos los
miembros del equipo poseer competencias y habilidades idénti-
cas? ¿Qué rasgos de personalidad o carácter son deseables en un
analista de sistemas que trabaje en el desarrollo de comercio elec-
trónico?
negocios. A menudo este trabajo no es un verdadero proyecto de sistemas, sino que supone una pequeña modifi-
cación o decisión que afecta a un solo departamento.
Como experto en soporte usted no administra el proyecto; simplemente actúa como recurso para quienes lo
administran. Si usted es un analista de sistemas empleado por una organización de manufactura o de servicios,
tal vez muchas de sus actividades diarias correspondan a este rol.
El analista de sistemas como agente de cambio
El rol más extenso y responsable del analista de sistemas es el de agente de cambio, ya sea interno o externo,
para la empresa. Como analista, usted actúa como un agente de cambio cada vez que realiza alguna de las ac-
tividades en el ciclo de vida del desarrollo de sistemas (que veremos en la siguiente sección) y está presente e
interactúa con los usuarios y la empresa durante un periodo extendido (de dos semanas hasta más de un año).
Podemos definir a un agente de cambio como una persona que actúa como catalizador para el cambio, desarrolla
un plan de cambio y trabaja con otros para facilitarlo.
Su presencia en la empresa genera un cambio; como analista de sistemas debe reconocer este hecho y utili-
zarlo como punto inicial para su análisis. Debe interactuar con los usuarios y la administración (si no son lo mismo)
desde las primeras etapas del inicio de su proyecto, pues sin su ayuda usted no podrá comprender qué necesitan
para apoyar su trabajo en la organización, y no se podrá llevar a cabo el verdadero cambio.www.xlibros.com

8 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
1
7
6 5
4
Desarrollo
y documentación
del software
3
22 Determinación de los
requerimientos humanos
de información
Análisis de las
necesidades
del sistema
Diseño
del sistema
recomendado
Prueba
y mantenimiento
del sistema
Implementación
y evaluación
del sistema
Identificación de los problemas,
oportunidades y objetivos
FIGURA 1.3
Las siete fases del ciclo de
desarrollo de sistemas (SDLC).
Si el cambio (es decir, las mejoras que se pueden realizar en la empresa por medio de los sistemas de infor-
mación) parece garantizado después del análisis, el siguiente paso es desarrollar un plan junto con las personas
que deben llevarlo a cabo. Una vez que se llega a un consenso en cuanto al cambio que se debe realizar, usted
debe interactuar en forma constante con todos los que vayan a cambiar.
En el rol de agente de cambio, un analista de sistemas aboga por una vía particular de cambio involucrada
con el uso de sistemas de información. También enseña a los usuarios el proceso del cambio, ya que los cambios
en el sistema de información no ocurren por separado, sino que producen cambios consecuentes en el resto de la
organización.
Cualidades del analista de sistemas
A partir de las anteriores descripciones de roles, es fácil deducir que un analista de sistemas exitoso debe poseer
un amplio rango de cualidades. Aunque los perfiles pueden variar de un caso específico a otro, hay ciertas cuali-
dades que la mayoría de los analistas de sistemas parecen tener.
Por encima de todo, el analista es un solucionador de problemas: una persona que ve el análisis de los
problemas como un reto y se divierte al idear soluciones factibles. Cuando sea necesario, el analista debe tener
la capacidad de lidiar de manera sistemática con la situación existente mediante la aplicación habilidosa de
herramientas, técnicas y experiencia. El analista también debe ser un comunicador capaz de crear relaciones
significativas con otras personas durante periodos extendidos de tiempo. Los analistas de sistemas necesitan
ser capaces de comprender las necesidades de los humanos al interactuar con la tecnología, además de que
necesitan suficiente experiencia con las computadoras como para programar, comprender las capacidades de
las computadoras, deducir los requerimientos de información de los usuarios y comunicar lo que se necesita a
los programadores. También deben poseer una sólida ética personal y profesional para poder dar forma a las
relaciones con sus clientes.
El analista de sistemas debe ser un individuo disciplinado y motivado, y tener capacidad para coordinar
tanto a personas como recursos variados para llevar a cabo los proyectos. El análisis de sistemas es una carrera
exigente, pero como compensación siempre está en continua evolución y ofrece nuevos retos.
EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
En este capítulo hemos hecho referencia a la metodología sistemática con la que los analistas llevan a cabo el
análisis y diseño de los sistemas de información. Gran parte de ello se expresa en lo que conocemos como el ciclo
de vida del desarrollo de sistemas (SDLC). El SDLC es una metodología en fases para el análisis y diseño, de
acuerdo con la cual los sistemas se desarrollan mejor al utilizar un ciclo específico de actividades del analista y
los usuarios.
Los analistas no se han puesto de acuerdo sobre la cantidad de fases que hay en el SDLC, pero por lo ge-
neral alaban su metodología organizada. En este libro vamos a dividir el ciclo en siete fases, como se muestra
en la figura 1.3. Aunque cada fase se presenta de manera discreta, en realidad nunca se puede llevar a cabo
como un paso separado, sino que varias actividades pueden ocurrir al mismo tiempo, e incluso se pueden re-
petir.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 9
Incorporación de las consideraciones de la interacción humano-computadora
En años recientes, el estudio de la interacción humano-computadora (HCI) se ha vuelto cada vez más impor-
tante para los analistas de sistemas. Aunque la definición sigue evolucionando, los investigadores caracterizan
a la HCI como el “aspecto de una computadora que permite las comunicaciones e interacciones entre ella y los
humanos. Es el nivel de la computadora que está entre ella y los humanos” (Zhang, Carey, Te’eni & Tremaine,
2005, p. 518). Los analistas que utilizan una metodología HCI se enfocan en las personas en vez del trabajo
a realizar o la TI involucrada. Su metodología para un problema es multifacética, ya que analiza los “factores
humanos ergonómicos, cognitivos, afectivos y de comportamiento involucrados en las tareas de los usuarios,
los procesos de solución de problemas y el contexto de la interacción” (Zhang, Carey, Te’eni & Tremaine,
2005, p. 518). La interacción entre humano y computadora se concentra en las necesidades humanas en vez
de enfocarse primero en las necesidades de la organización y del sistema. Los analistas que adoptan los prin-
cipios de la HCI examinan una amplia variedad de necesidades en el contexto de los usuarios humanos que
interactúan con la tecnología de información para completar sus tareas y resolver problemas. Aquí también
se toman en cuenta los factores físicos o ergonómicos, los cognitivos relacionados con la facilidad de uso, los
estéticos, los relacionados con una experiencia de uso agradable, y los aspectos conductuales relacionados con
la utilidad del sistema.
La HCI también se considera una metodología centrada en los humanos, que pone a las personas por encima
de la estructura o cultura organizacional al crear sistemas. Cuando los analistas emplean la HCI como un lente
para filtrar el mundo, su trabajo posee una calidad distinta a la del trabajo de aquellos quienes no poseen esta
perspectiva.
Su carrera profesional se puede beneficiar gracias a la sólida comprensión de los fundamentos de la HCI.
La demanda de analistas capaces de incorporar la HCI al proceso de desarrollo de sistemas sigue en aumento, a
medida que cada vez más empresas se dan cuenta de que la calidad de los sistemas y la calidad de la vida laboral
se pueden mejorar mediante el empleo de una metodología centrada en los humanos desde el inicio de un pro-
yecto.
La aplicación de los principios de la interacción humano-computadora implica descubrir y resolver las frus-
traciones que los usuarios experimentan al usar tecnologías de información, entre las que se cuenta la sospecha
de que el analista malentendió el trabajo que se iba a realizar, las tareas involucradas y cuál era la mejor ma-
nera de apoyarlas; sensación de impotencia o falta de control al trabajar con el sistema; violaciones intencionales
a la privacidad; problemas al navegar por las pantallas y menús del sistema, y una discrepancia general entre el
sistema que se diseñó y la forma en que los mismos usuarios piensan con respecto a sus procesos laborales.
Cuando los analistas de sistemas adoptan una metodología HCI, pueden erradicar o minimizar las malas
apreciaciones y los errores de diseño que provocan el rechazo de los usuarios hacia los nuevos sistemas o su
abandono poco tiempo después de la implementación.
Los investigadores de la HCI observan ventajas al incluir la HCI en cada fase del SDLC. Es una metodolo-
gía que vale la pena usar y para reflejar esto trataremos de llevar los intereses humanos en forma explícita a cada
fase del SDLC. Como estudiante de análisis de sistemas, usted también puede ofrecer una nueva perspectiva al
SDLC para identificar las oportunidades que tienen los diseñadores de lidiar con las cuestiones de la HCI y las
formas en que los usuarios pueden tener una participación más primordial en cada fase del SDLC. En el capítulo 14
nos dedicaremos a examinar el rol del analista de sistemas en cuanto a diseñar sistemas e interfaces centrados en
los humanos desde la perspectiva de la HCI.
Identificación de los problemas, oportunidades y objetivos
En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se encarga de identificar correctamente
los problemas, las oportunidades y los objetivos. Esta etapa es imprescindible para el éxito del resto del proyecto:
ya que a nadie le gusta desperdiciar el tiempo resolviendo un problema mal caracterizado.
En la primera fase el analista debe analizar con honestidad lo que está ocurriendo en la empresa. Después,
junto con otros miembros de la organización, debe comenzar a señalar los problemas. A menudo, otras personas
habrían planteado también estos problemas, razón por la cual se llamó en un principio al analista. Las oportuni-
dades residen en las situaciones que el analista cree poder mejorar mediante el uso de sistemas de información
computarizados. Al aprovechar estas oportunidades, la empresa puede obtener una ventaja competitiva o estable-
cer un estándar en la industria.
La identificación de los objetivos también es un componente importante de la primera fase. El analista debe
descubrir primero qué trata de hacer la empresa; después debe ser capaz de determinar si alguno de los aspec-
tos de las aplicaciones de los sistemas de información puede ayudar a que la empresa logre sus objetivos al en-
frentar problemas u oportunidades específicos.
Las personas involucradas en la primera fase son los usuarios, los analistas y los administradores de sistemas
que coordinan el proyecto. En esta fase las actividades consisten en entrevistar a los encargados de la adminis-
tración de los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar loswww.xlibros.com

10 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
resultados. El resultado de esta fase es un informe de viabilidad, el cual contiene la definición de un problema y
sintetiza los objetivos. Después, la administración de la empresa debe tomar una decisión en cuanto a proceder o
no con el proyecto propuesto. Si el grupo de usuarios no tiene suficientes fondos en su presupuesto o desea hacer
frente a problemas que no están relacionados, o si los problemas no requieren un sistema computacional, tal vez
se pueda recomendar una solución distinta y el proyecto de sistemas no continúe.
Determinación de los requerimientos de información del factor humano
La siguiente fase a la que entra el analista es determinar las necesidades de los usuarios involucrados, me-
diante el uso de varias herramientas, para comprender la forma en que interactúan en el contexto laboral con
sus sistemas de información actuales. El analista utilizará métodos interactivos como entrevistas, muestreos e
investigación de datos duros, además de los cuestionarios y los métodos discretos, como observar el compor-
tamiento de los encargados al tomar las decisiones y sus entornos de oficina, y los métodos integrales como la
creación de prototipos.
El analista utilizará estos métodos para plantear y responder muchas preguntas relacionadas con la interacción
humano-computadora (HCI), incluyendo preguntas tales como: “¿Cuáles son las fortalezas y limitaciones físicas de
los usuarios?”, o dicho en otras palabras, “¿qué hay que hacer para que el sistema sea perceptible, legible y seguro?”,
“¿cómo puede diseñarse el nuevo sistema para que sea fácil de usar, aprender y recordar?”, “¿cómo puede el sistema
ser agradable o incluso divertido de usar?”, “¿cómo puede el sistema apoyar las tareas laborales individuales de un
usuario y buscar nuevas formas de hacerlas más productivas?”.
En la fase de requerimientos del SDLC, el analista se esfuerza por comprender qué información requieren
los usuarios para realizar sus trabajos. En este punto el analista examina cómo hacer que el sistema sea útil para
las personas involucradas. ¿Cómo puede el sistema ofrecer un mejor apoyo para las tareas individuales que se
deben llevar a cabo? ¿Qué nuevas tareas habilita el nuevo sistema que los usuarios no podían realizar sin él?
¿Cómo se puede crear el sistema de manera que extienda las capacidades de un usuario más allá de lo provisto
por el sistema anterior? ¿Cómo puede el analista crear un sistema gratificante para los trabajadores?
Las personas involucradas en esta fase son los analistas y los usuarios, por lo general los gerentes y los tra-
bajadores de operaciones. El analista de sistema debe conocer los detalles sobre las funciones del sistema actual:
el quién (las personas involucradas), el qué (la actividad de la empresa), el dónde (el entorno en el que se lleva a
cabo el trabajo), el cuándo (la coordinación) y el cómo (de qué manera particular se realizan los procedimientos
actuales) de la empresa a la que está estudiando. Después, el analista debe preguntar por qué la empresa utiliza el
sistema actual. Puede haber buenas razones por las cuales la empresa trabaje con los métodos actuales, razón por
la que se deben tener en cuenta al diseñar un nuevo sistema.
El desarrollo ágil es una metodología orientada a objetos (OOA) para el desarrollo de sistemas, en la cual se
incluye un método de desarrollo (junto con la generación de los requerimientos de información) así como herra-
mientas de software. En el capítulo 6 veremos este tipo de desarrollo, junto con los prototipos (hay más informa-
ción sobre las metodologías orientadas a objetos en el capítulo 10).
No obstante, si la razón de seguir con las operaciones actuales es que “siempre se ha hecho de esa forma”, el
analista querrá mejorar los procedimientos. Al terminar esta fase, el analista deberá comprender la forma en que los
usuarios realizan su trabajo al interactuar con una computadora y deberá empezar a comprender cómo mejorar la
utilidad y capacidad de uso del nuevo sistema. También deberá saber cómo funciona la empresa y tener información
completa sobre personas, objetivos, datos y procedimientos involucrados.
Análisis de las necesidades del sistema
La siguiente fase que debe llevar a cabo el analista de sistemas involucra el análisis de las necesidades del sis-
tema. Aquí también hay herramientas y técnicas especiales que ayudan al analista a realizar las determinaciones
de los requerimientos. Las herramientas como los diagramas de flujo de datos (DFD) para graficar la entrada, los
procesos y la salida de las funciones de la empresa, o los diagramas de actividad o de secuencia para mostrar la
secuencia de los eventos, sirven para ilustrar a los sistemas de una manera estructurada y gráfica. A partir de los
diagramas de flujo de datos, de secuencia u otros tipos de diagramas se debe desarrollar un diccionario de datos
para enlistar todos los elementos de datos utilizados en el sistema, así como sus especificaciones.
Durante esta fase, el analista de sistemas también analiza las decisiones estructuradas llevadas a cabo. Las
decisiones estructuradas son aquellas para las que se pueden determinar condiciones, alternativas de condición,
acciones y reglas de acción. Hay tres métodos principales para el análisis de las decisiones estructuradas: inglés/
español estructurado, tablas de decisión y árboles de decisión.
En este punto del SDLC, el analista de sistemas prepara una propuesta de sistemas en la que sintetiza todo
lo que ha averiguado sobre los usuarios, la capacidad de uso y la utilidad de los sistemas actuales; incluye un
análisis de costo-beneficio de las alternativas y, si se requiere, hace recomendaciones. Si la administración acepta
una de las recomendaciones, el análisis continúa por esa vía. Cada problema de sistemas es único, por lo que
nunca hay sólo una solución correcta. La manera en que se formule una recomendación o solución depende dewww.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 11
las cualidades individuales y la capacitación profesional de cada analista, y de su interacción con los usuarios en
el contexto de su entorno laboral.
Diseño del sistema recomendado
En la fase de diseño del SDLC, el analista de sistemas utiliza la información recolectada antes para realizar el diseño
lógico del sistema de información. El analista diseña los procedimientos para ayudar a que los usuarios introduzcan
los datos con precisión, de manera que los datos que entren al sistema de información sean los correctos. Además, el
analista debe ayudar a que los usuarios completen la entrada de datos efectiva al sistema de información mediante
el uso de las técnicas del buen diseño de formularios y páginas Web o pantallas.
Parte del diseño lógico del sistema de información es idear la HCI. La interfaz conecta al usuario con el
sistema, por lo que es extremadamente importante. La interfaz del usuario se diseña con ayuda de los usuarios
para asegurar que el sistema sea perceptible, legible y seguro, así como atractivo y divertido de usar. Ejemplos de
interfaces de usuario físicas son el teclado (para escribir las preguntas y respuestas), los menús en pantalla (para
obtener los comandos de los usuarios) y varios tipos de interfaces gráficas de usuario (GUI) basadas en un ratón
o una pantalla táctil.
La fase de diseño también incluye el diseño de bases de datos que almacenarán gran parte de los datos nece-
sarios para los encargados de tomar las decisiones en la organización. Los usuarios se benefician de una base de
datos bien organizada que sea lógica para ellos y se corresponda con la forma en que ven su trabajo. En esta fase,
el analista también trabaja con los usuarios para diseñar una salida (ya sea en pantalla o impresa) que cumpla con
sus necesidades de información.
Por último, el analista debe diseñar controles y procedimientos de respaldo para proteger el sistema y los
datos, y para producir paquetes de especificación de programas para los programadores. Cada paquete debe
contener los diseños de las entradas y las salidas, las especificaciones de los archivos y los detalles sobre el pro-
cesamiento; también puede incluir árboles o tablas de decisión, UML o diagramas de flujo de datos, junto con
los nombres y las funciones de cualquier código previamente escrito dentro de la empresa o que utilice código u
otras bibliotecas de clases.
Desarrollo y documentación del software
En la quinta fase del SDLC, el analista trabaja con los programadores para desarrollar el software original reque-
rido. Durante ella, el analista desarrolla junto con los usuarios una documentación efectiva para el software, inclu-
yendo manuales de procedimientos, ayuda en línea, sitios Web con preguntas frecuentes (FAQ) y archivos Léame
(Read Me) para incluir con el nuevo software. Como los usuarios están involucrados desde el principio, la fase de
documentación debe lidiar con las preguntas que hicieron y resolvieron junto con el analista. La documentación
indica a los usuarios cómo deben usar el software y qué deben hacer en caso de que ocurran problemas.
Los programadores desempeñan un rol clave en esta fase, ya que diseñan, codifican y eliminan los errores
sintácticos de los programas de computadora. Para asegurar la calidad, un programador puede llevar a cabo un
recorrido por el diseño o por el código para explicar las porciones complejas del programa a un equipo formado
por otros programadores.
Prueba y mantenimiento del sistema
Antes de utilizar el sistema de información, se debe probar. Es mucho menos costoso detectar los problemas an-
tes de entregar el sistema a los usuarios. Una parte del procedimiento de prueba es llevado a cabo por los progra-
madores solos; la otra la realizan junto con los analistas de sistemas. Primero se completa una serie de pruebas
para señalar los problemas con datos de muestra y después se utilizan datos reales del sistema actual. A menudo,
los planes de prueba se crean en las primeras etapas del SDLC y se refinan a medida que el proyecto progresa.
El mantenimiento del sistema y la documentación de este mantenimiento empieza en esta fase y se lleva a cabo
de manera rutinaria durante toda la vida del sistema de información. Gran parte del trabajo rutinario del programa-
dor consiste en el mantenimiento, por lo cual las empresas invierten una gran cantidad de dinero en este proceso.
Ciertos procedimientos de mantenimiento, como las actualizaciones de los programas, se pueden llevar a cabo a
través del sitio Web del distribuidor. Muchos de los procedimientos sistemáticos que emplea el analista durante el
SDLC pueden ayudar a asegurar que el mantenimiento siempre se mantenga en el nivel mínimo necesario.
Implementación y evaluación del sistema
En esta última fase del desarrollo de sistemas, el analista ayuda a implementar el sistema de información. En esta
fase hay que capacitar a los usuarios para operar el sistema. Los distribuidores se encargan de una parte de la
capacitación, pero la supervisión de la capacitación es responsabilidad del analista de sistemas. Además, el ana-
lista necesita planear una conversión sin problemas del sistema antiguo al nuevo. Este proceso incluye convertir
los archivos de los formatos anteriores a los nuevos, o crear una base de datos, instalar equipo y llevar el nuevo
sistema a producción.www.xlibros.com

12 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
La evaluación se incluye como parte de esta fase final del SDLC principalmente por cuestiones informativas.
En realidad, la evaluación se realiza durante cada fase. El criterio clave que debemos satisfacer es si los usuarios
previstos están utilizando el sistema.
Hay que tener en cuenta que a menudo el trabajo relacionado con los sistemas es cíclico. Cuando un analista
termina una fase del desarrollo de sistemas y continúa con la siguiente, al descubrir un problema tal vez se vea
obligado a regresar a la fase anterior y modificar el trabajo que realizó ahí.
El impacto del mantenimiento
Una vez instalado el sistema hay que darle mantenimiento, lo cual implica que tal vez haya que realizar mo-
dificaciones en los programas de computadora y mantenerlos actualizados. La figura 1.4 muestra la cantidad
promedio de tiempo que se invierte en el mantenimiento de una instalación de MIS común. Las estimaciones
del tiempo invertido por los departamentos en el mantenimiento varían desde un 48 hasta un 60 por ciento del
tiempo total invertido en el desarrollo de los sistemas. Queda muy poco tiempo libre para el desarrollo de nuevos
sistemas. A medida que aumenta el número de programas escritos, también aumenta la cantidad de manteni-
miento que se requiere.
FIGURA 1.MAC
Windows ejecutándose en una Mac mediante el software de virtualización conocido como VM Fusion.
A T R A C T I V O D E L A M A C
En el hogar y en nuestras visitas a los campus de universidades y empresas en todo el mundo hemos observado que cada
vez más estudiantes y las organizaciones muestran un interés por la Mac. Por ello pensamos que sería interesante mos-
trar algunas de las opciones que tiene un diseñador de sistemas al respecto de esta plataforma. Al momento de escribir
este libro, aproximadamente una de cada siete computadoras personales que se compran en los Estados Unidos es Mac.
Las Mac son equipos de calidad basados en procesadores Intel que ejecutan un competente sistema operativo nativo,
pero también pueden ejecutar Windows, por lo que en definitiva cualquier cosa que se pueda hacer en una PC se puede
hacer también en una Mac. Una forma de ejecutar Windows es arrancar directamente la Mac con el sistema Windows
(una vez instalado); otra forma es usar software de virtualización como VM Fusion, el cual mostramos en la figura
1.MAC.
Los seguidores de las Mac citan muchas razones por las cuales las utilizan, incluyendo una mejor seguridad inte-
grada en el sistema operativo de la Mac, respaldos inteligentes mediante la máquina de tiempo integrada, la multitud de
aplicaciones ya incluidas, la confiabilidad de la configuración y el trabajo en red, y la capacidad de sincronizar las Mac
con otros equipos Mac y con el iPhone. Para nosotros, la razón más convincente es su diseño en sí.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 13
Mantenimiento de los
sistemas existentes
60%
Nuevos sistemas
y otras actividades
40%
FIGURA 1.4
Algunos investigadores estiman
que la cantidad de tiempo
invertido en el mantenimiento de
sistemas puede ser hasta del 60
por ciento del tiempo total
invertido en los proyectos de
sistemas.
El mantenimiento se lleva a cabo por dos razones. La primera es para corregir los errores de software. Sin
importar qué tan minuciosas sean las pruebas en el sistema, se pueden infiltrar errores o ‘bugs’ en los programas
computacionales. Los ‘bugs’ en el software comercial de PC se documentan comúnmente como “anomalías co-
nocidas” y se corrigen al momento de liberar nuevas versiones, o liberando una versión provisional. En el soft-
ware personalizado (también conocido como software hecho a la medida), los ‘bugs’ se deben corregir a medida
que se van detectando.
La otra razón de realizar mantenimiento en los sistemas es para mejorar las capacidades del software en
respuesta a las necesidades cambiantes de la organización, que por lo general implica una de las siguientes tres
situaciones:
1. Con frecuencia los usuarios solicitan características adicionales a medida que se familiarizan con el sistema
computacional y sus capacidades.
2. La empresa cambia con el tiempo.
3. El hardware y el software cambian a un ritmo acelerado.
La figura 1.5 muestra la cantidad de recursos (por lo general tiempo y dinero) que se invierten en el de-
sarrollo y mantenimiento de sistemas. El área bajo la curva representa la cantidad total invertida en dólares.
Podemos ver que, a través del tiempo, es probable que el costo total del mantenimiento exceda al costo del
desarrollo de sistemas. En cierto punto es más factible realizar un nuevo estudio de sistemas, debido a que el
costo de continuar con el mantenimiento es sin duda mayor que el de crear un sistema de información total-
mente nuevo.
En resumen, el mantenimiento es un proceso continuo que se realiza a lo largo del ciclo de vida de un sis-
tema de información. Una vez que se instala el sistema de información, por lo general el mantenimiento implica
corregir los errores del programa que no se habían detectado antes. Una vez corregidos, el sistema se acerca a un
estado estable para proveer un servicio confiable a sus usuarios. Durante este periodo, el mantenimiento puede
consistir en eliminar unos cuantos ‘bugs’ que no se detectaron antes y actualizar el sistema con mejoras menores.
Sin embargo, a medida que pasa el tiempo y evolucionan tanto la empresa como la tecnología, el esfuerzo de
mantenimiento aumenta en forma considerable.
Cantidad
de recursos
consumidos,
tiempo
y dinero
Desarrollo
de sistemas
‘Bugs’ subsecuentes
a la instalación Modificaciones
menores debido a
‘bugs’ y mejoras
Cambios importantes
tanto en la empresa
como en la tecnología
Tiempo
Día de la
instalación
FIGURA 1.5
Consumo de los recursos durante
el tiempo de vida del sistema.www.xlibros.com

14 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
USO DE HERRAMIENTAS CASE
Los analistas que adoptan la metodología SDLC a menudo se benefician de las herramientas de productividad,
conocidas como herramientas de Ingeniería de Software Asistida por Computadora (CASE), las cuales se crea-
ron de manera explícita para mejorar el trabajo rutinario a través del uso del soporte automatizado. Los analistas
emplean herramientas CASE para aumentar la productividad, comunicarse con los usuarios de una manera más
efectiva e integrar el trabajo que realizan en el sistema, desde el inicio hasta el fin del ciclo de vida.
Visible Analyst (VA) es un ejemplo de herramienta CASE que permite a los analistas de sistemas realizar
planificación, análisis y diseño en forma gráfica para crear bases de datos y aplicaciones cliente/servidor comple-
jas. Visible Analyst, aunado a otro producto de software conocido como Microsoft Visio, permite a los usuarios
dibujar y modificar diagramas con facilidad.
Los analistas y usuarios en general reportan que las herramientas CASE les ofrecen un medio de comu-
nicación relacionado con el sistema durante su conceptualización. Mediante el uso de soporte automatizado
que incluye resultados en pantalla, los clientes pueden ver de inmediato la forma en que fluyen los datos y
cómo se representan otros conceptos del sistema, para así poder solicitar correcciones o modificaciones que
hubieran requerido de mucho más tiempo si se utilizaran herramientas anteriores.
Algunos analistas marcan la diferencia entre las herramientas CASE superiores e inferiores. Una herra-
mienta CASE superior permite al analista crear y modificar el diseño del sistema. Toda la información sobre
el proyecto se almacena en una enciclopedia conocida como repositorio CASE, una extensa colección de
registros, elementos, diagramas, pantallas, informes y demás información relacionada (vea la figura 1.6). Es
posible producir informes del análisis mediante el uso de la información del repositorio para mostrar en qué
partes está incompleto el diseño o dónde hay errores. Las herramientas CASE superiores también ayudan a
sustentar el modelado de los requerimientos funcionales de una organización, auxiliar a los analistas y usua-
rios para dibujar los límites de un proyecto dado y ayudarlos a visualizar la forma en que el proyecto encaja
con otras partes de la organización.
Las herramientas CASE inferiores se utilizan para generar código fuente de computadora, con lo cual se eli-
mina la necesidad de programar el sistema. La generación de código ofrece varias ventajas: 1) el sistema se puede
producir con más rapidez que si se escribieran programas computacionales; 2) la cantidad de tiempo invertido
en el mantenimiento se reduce con la generación de código; 3) se puede generar código en más de un lenguaje
computacional, por lo que es más sencillo migrar los sistemas de una plataforma a otra; 4) la generación de có-
digo provee una manera efectiva en costo de personalizar los sistemas que se compran a terceros distribuidores
para ajustarlos a las necesidades de la organización, y 5) el código generado está libre de los errores típicos de
los programas computacionales.
LA METODOLOGÍA ÁGIL
Aunque este texto tiende a enfocarse en el SDLC —la metodología más utilizada en la práctica—, el analista
deberá reconocer algunas veces que la organización podría beneficiarse de una metodología alternativa. Tal vez
recientemente un proyecto de sistemas en el que se utilizaba una metodología estructurada falló o quizás las
subculturas de la organización, compuestas por varios grupos de usuarios distintos, parecen identificarse más con
el uso de un método alternativo. Es imposible hacer justicia a estos métodos en un espacio pequeño; cada uno
merece y ha inspirado sus propios libros e investigaciones. Sin embargo, mencionamos estas metodologías con la
esperanza de que tome conciencia de que, bajo ciertas circunstancias, tal vez su organización quiera considerar
una alternativa o suplemento al análisis y diseño estructurado y al SDLC.
La metodología ágil es una metodología de desarrollo de software que se basa en valores, principios y prác-
ticas básicas. Los cuatro valores son comunicación, simpleza, retroalimentación y valentía. Recomendamos que
los analistas de sistemas adopten estos valores en todos los proyectos que emprendan y no sólo cuando adopten
la metodología ágil.
Para poder terminar un proyecto, a menudo hay que realizar ciertos ajustes en la administración del mismo.
En el capítulo 6 veremos que los métodos ágiles pueden asegurar que un proyecto se complete con éxito me-
diante un ajuste en los importantes recursos de tiempo, costo, calidad y alcance. Cuando se incluyen estas cuatro
variables de control en forma apropiada en la planificación, hay un estado de equilibrio entre los recursos y las
actividades necesarias para completar el proyecto.
Es más notable llevar las prácticas de desarrollo al extremo cuando se persiguen prácticas únicas para el de-
sarrollo ágil. En el capítulo 6 hablaremos sobre cuatro prácticas ágiles básicas: liberaciones de versiones cortas,
la semana de trabajo de 40 horas, hospedar un cliente en el sitio y utilizar programación en pareja. A primera
vista estas prácticas parecen extremas, pero como veremos más adelante, podemos aprender ciertas lecciones
importantes al incorporar muchos de los valores y prácticas de la metodología ágil a los proyectos de análisis y
diseño de sistemas.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 15
AGREGAR CLIENTE
NÚMERO XXXXXX
NOMBRE XXXXXXXXXXXX
CALLE XXXXXXXXXXXX
CIUDAD XXXXXXXXXXXX
ESTADO XX
CP XXXXX-XXXX
INFORME DEL ANÁLISIS DE VENTAS
DESCRIPCIÓN
DEL ARTÍCULO
VENTAS
TOTALES
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
ZZ,ZZ9
ZZ,ZZ9
ZZ,ZZ9
ZZ,ZZ9
ZZ,ZZ9
ZZ,ZZ9
Diseño de pantallas
e informes
Diagramas y modelos
de sistemas
DO WHILE NOT fin de archivo
Leer registro del artículo
IF artículo está bajo en existencias
Imprimir orden de compra
Actualizar registro del artículo
ENDIF
ENDDO
Diccionario de datos
y lógica de procesos
Administración
del proyecto
Requerimientos del sistema
• Agregar nuevos clientes
• Identificar los artículos que se
venden con lentitud y los que
se venden con rapidez
• Introducir los pedidos
de los clientes
• Analizar el saldo de crédito
del cliente
• Mantener un inventario adecuado
Entregables
• Agregar la pantalla para el cliente
• Informe de análisis de artículos
• Pantalla de captura de pedidos
de los clientes
• Pantalla de consultas de los
clientes
• Programa de órdenes de
compra de los distribuidores
• Pronóstico estacional
Número +
Descripción +
Costo +
Precio +
Cantidad en existencia +
Cantidad en pedido +
Punto para reabastecer +
Ventas mensuales +
Ventas del año a la fecha
Artículo =
FIGURA 1.6
El concepto de repositorio.
Proceso de desarrollo para un proyecto ágil
Hay actividades y comportamientos que determinan la manera en que actúan los miembros del equipo y los clien-
tes durante el desarrollo de un proyecto ágil. Dos palabras que caracterizan a un proyecto realizado mediante una
metodología ágil son interactivo e incremental. Si examina la figura 1.7 podrá ver que hay cinco etapas: explo-
ración, planeación, iteraciones para la liberación de la primera versión, puesta en producción y mantenimiento.
Observe que las primeras tres flechas grises que iteran de vuelta a la caja “Iteraciones” simbolizan los cambios
incrementales creados por medio de los procesos repetidos de prueba y retroalimentación que en cierto momento
conducen a un sistema estable pero en evolución. Observe además que el ritmo de iteraciones aumenta una vez
que se libera el producto. La flecha sale de la etapa de mantenimiento y regresa a la etapa de planeación, de
manera que hay un ciclo continuo de retroalimentación que involucra a los clientes y al equipo de desarrollo a
medida que se ponen de acuerdo para alterar el sistema en evolución.
EXPLORACIÓN Durante ella usted explorará su entorno para evaluar su convicción de que puede y debe lidiar
con el problema mediante el desarrollo ágil, ensamblará el equipo y evaluará las habilidades de sus miembros.
Esta etapa puede requerir desde unas cuantas semanas (si conoce de antemano a los miembros de su equipo y la
tecnología que va a usar) hasta unos cuantos meses (si todo es nuevo). También tendrá que examinar activamentewww.xlibros.com

16 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Planeación
Exploración
Mantenimiento
Iteraciones para
la liberación de la
primera versión
Puesta en producción
Los métodos ágiles
involucran al cliente
en muchas iteraciones
antes de liberar
la primera versión ...
...e incrementan el
ritmo de iteraciones
una vez que se libera
el producto.
FIGURA 1.7
Las cinco etapas del proceso de
desarrollo de modelado ágil
muestran que las iteraciones
frecuentes son esenciales para un
desarrollo exitoso del sistema.
las tecnologías potenciales necesarias para crear el sistema. Durante esta etapa debe practicar con la estimación
del tiempo necesario para realizar varias tareas. En la exploración, los clientes también experimentan escribiendo
historias de los usuarios. El punto es hacer que el cliente refine una historia con el detalle suficiente como para
que usted pueda estimar en forma competente la cantidad de tiempo necesaria para crear la solución y convertirla
en el sistema que está planeando. Todo en esta etapa tiene que ver con adoptar una actitud juguetona y curiosa
hacia el entorno de trabajo, sus problemas, tecnologías y personas.
PLANEACIÓN La siguiente etapa del proceso de desarrollo ágil se llama planeación. Al contrario de la primera
etapa, la planeación tal vez sólo requiera de unos cuantos días. En esta etapa, usted y sus clientes se ponen de
acuerdo en una fecha, que puede ser cualquier día a partir de dos meses hasta medio año después de la fecha
en curso, para entregar soluciones a sus problemas empresariales más estresantes (usted se concentrará en el
conjunto más pequeño y valioso de historias). Si sus actividades de exploración fueron suficientes, esta etapa
debe ser muy corta.
Todo el proceso de planeación ágil se ha caracterizado mediante la idea de un juego de planeación según
la idea de Beck. El juego de planeación establece reglas que pueden ayudar a formular la relación del equipo de
desarrollo ágil con sus clientes empresariales. Aunque las reglas forman una idea de cómo quiere usted que actúe
cada una de las partes durante el desarrollo, no están diseñadas para sustituir una relación. Son la base para crear
y mantener una relación.
Entonces, utilizamos la metáfora de un juego. Para ello hablaremos en términos del objetivo del juego,
la estrategia a perseguir, las piezas a mover y los jugadores involucrados. El objetivo del juego es maximizar
el valor del sistema producido por el equipo ágil. Para poder averiguar el valor, usted debe deducir los costos
de desarrollo y el tiempo, los gastos y la incertidumbre requeridos para que el proyecto de desarrollo pueda
continuar.
La estrategia que persigue el equipo de desarrollo ágil siempre tiene una incertidumbre limitante (minimiza-
ción del riesgo). Para hacer esto, el equipo diseña la solución más simple posible, pone el sistema en producción
tan pronto como sea posible, obtiene retroalimentación del cliente empresarial sobre lo que está funcionando y
adapta su diseño a partir de ahí.
Las tarjetas de historias se convierten en las piezas del juego de planeación que describen con brevedad la
tarea, proveen anotaciones y un área para rastrear las tareas.
Hay dos jugadores principales en el juego de planeación: el equipo de desarrollo y el cliente empresarial. No
siempre es fácil decidir qué grupo empresarial en particular será el cliente empresarial, ya que el proceso ágil eswww.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 17
un rol excepcionalmente exigente para el cliente. Los clientes deciden qué debe abordar primero el equipo de de-
sarrollo. Sus decisiones establecerán prioridades y revisarán la funcionalidad durante todo el proceso.
ITERACIONES PARA LA LIBERACIÓN DE LA PRIMERA VERSIÓN La tercera etapa en el proceso de desarrollo ágil
está compuesta por las iteraciones para la liberación de la primera versión. Por lo general éstas son iteraciones
(ciclos de prueba, retroalimentación y modificación) de aproximadamente tres semanas de duración. Usted se
esforzará en bosquejar toda la arquitectura del sistema, aun y cuando sólo esté en forma de bosquejo o esqueleto.
Uno de los objetivos es realizar pruebas funcionales escritas por el cliente al final de cada iteración. Durante
la etapa de las iteraciones también debe preguntarse si hay que alterar el itinerario de trabajo o si está lidiando
con demasiadas historias. Convierta cada iteración exitosa en pequeños rituales e involucre en ellos tanto a los
clientes como a los desarrolladores. Celebre siempre su progreso aunque éste sea pequeño, debido a que esto
forma parte de la cultura de motivar a todos a que trabajen lo más duro que puedan en el proyecto.
PUESTA EN PRODUCCIÓN Durante esta fase se llevan a cabo varias actividades. El ciclo de retroalimentación se
agiliza de manera que en vez de recibir retroalimentación por una iteración cada tres semanas, las revisiones de
software se entregan en una semana. Puede instituir sesiones informativas diarias para que todos sepan lo que
los demás están haciendo. El producto se libera durante esta fase, pero se puede mejorar si se le agregan otras
características. Poner un sistema en producción es un suceso emocionante; disponga de tiempo para celebrar
con sus compañeros de equipo la ocasión. Uno de los lemas de la metodología ágil con el que todos estamos
sinceramente de acuerdo es que ¡desarrollar sistemas debe ser divertido!
MANTENIMIENTO Una vez liberado el sistema, debe seguir funcionando sin problemas. Es posible agregar
características, considerar las sugerencias más riesgosas de los clientes y a rotar los miembros del equipo. La
actitud que usted debe tomar en este punto del proceso de desarrollo es más conservadora que en cualquier otro.
Ahora tiene que desempeñar el papel de “guardián de la llama” en vez de ser el juguetón y curioso de la fase de
exploración.
ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADO A OBJETOS
El análisis y diseño de sistemas orientado a objetos (O-O) es una metodología diseñada para facilitar el desarro-
llo de sistemas que deben cambiar con rapidez en respuesta a los entornos empresariales dinámicos. El capítulo
10 le ayudará a comprender lo que es el análisis y diseño de sistemas orientado a objetos, la diferencia entre esta
metodología y la metodología estructurada del SDLC y cuándo puede ser apropiado utilizar una metodología
orientada a objetos.
Se cree que las técnicas orientadas a objetos funcionan bien en situaciones en las que los sistemas de in-
formación complejos pasan a través de un continuo proceso de mantenimiento, adaptación y rediseño. Las me-
todologías orientadas a objetos utilizan el estándar de la industria para modelar sistemas orientados a objetos,
conocido como lenguaje de modelado unificado (UML), para descomponer un sistema en un modelo de caso
de uso.
La programación orientada a objetos difiere de la programación tradicional por procedimientos en cuanto
a que examina a los objetos que forman parte de un sistema. Cada objeto es una representación computacional
de una cosa o evento real. Los objetos pueden ser clientes, artículos, pedidos, etcétera. Los objetos se repre-
sentan y agrupan mediante clases, las cuales son ideales para la reutilización y la facilidad de mantenimiento.
Una clase define el conjunto de atributos y comportamientos compartidos que se encuentran en cada objeto de
la clase.
Las fases en el UML son similares a las del SDLC. Como estos dos métodos comparten un modelado rígido
y exigente, se realizan a un ritmo más lento y reflexivo que las fases del modelado ágil. El analista pasa por las
fases del problema y de identificación, una fase de análisis y una fase de diseño, como se muestra en la figura
1.8. Aunque gran parte de los detalles específicos los veremos en los capítulos 2 y 10, los siguientes pasos mues-
tran una descripción breve del proceso del UML.
1. Definir el modelo de caso de uso.
En esta fase, el analista identifica a los actores y los eventos principales iniciados por los actores.
A menudo el analista empieza por dibujar un diagrama con figuras hechas con líneas que representan a los
actores y flechas que muestran las relaciones entre ellos. A esto se le conoce como diagrama de caso de uso
(capítulo 2) y representa el flujo estándar de eventos en el sistema. Después de esto, el analista por lo
general escribe un escenario de caso de uso (capítulo 2), que describe con palabras los pasos que se llevan a
cabo comúnmente.
2. Durante la fase de análisis de sistemas, empezar a dibujar diagramas de UML.
En la segunda fase (capítulo 10) el analista dibujará Diagramas de actividad, los cuales ilustran todas las
principales actividades en el caso de uso. Además el analista creará uno o más diagramas de secuencia parawww.xlibros.com

18 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Modificar diagramas
y completar
especificaciones
Desarrollar y
documentar
el sistema
Dibujar diagramas
de caso de uso
Escribir escenarios
de casos de uso
Derivar diagramas
de actividad de los
casos de uso
Desarrollar diagramas
de secuencia
Dibujar diagramas
de estado
Crear diagramas
de clases
Fase de análisis
de sistemas
Fase de diseño
de sistemas
Fase de identificación
de los problemas
Empezar el análisis y
diseño orientado a objetos
FIGURA 1.8
Los pasos en el proceso de
desarrollo de UML.
cada caso de uso, los cuales muestran la secuencia de actividades y su sincronización. Ésta es una
oportunidad para regresar y revisar los casos de uso, replantearlos y modificarlos si es necesario.
3. Continuar en la fase de análisis, desarrollar diagramas de clases.
Los sustantivos en los casos de uso son objetos que se pueden agrupar potencialmente en clases. Por
ejemplo, todo automóvil es un objeto que comparte características con otros automóviles. En conjunto
conforman una clase.
4. Aún en la fase de análisis, dibujar diagramas de estado.
Los diagramas de clases se utilizan para dibujar diagramas de estado, los cuales ayudan a comprender
procesos complejos que no se pueden derivar completamente mediante los diagramas de secuencia. Los
diagramas de estado son en extremo útiles para modificar los diagramas de clases, por lo que continúa el
proceso iterativo de modelado de UML.
5. Empezar el diseño de sistemas mediante la modificación de los diagramas de UML; después, completar las
especificaciones.
El diseño de sistemas significa modificar el sistema existente, para lo cual hay que modificar los
diagramas que se dibujaron en la fase anterior. Es posible usar estos diagramas para derivar clases, sus
atributos y métodos (éstos son simplemente operaciones). El analista tendrá que escribir especificaciones de
clase para cada una de las clases e incluir los atributos, métodos y sus descripciones. También desarrollará
especificaciones de los métodos en las que se detallen los requerimientos de entrada y salida para cada
método, junto con una descripción detallada del procesamiento interno del método.
6. Desarrollar y documentar el sistema.
UML es, obviamente, un lenguaje de modelado. Un analista podrá crear modelos maravillosos, pero
si el sistema no se desarrolla no tiene mucho sentido crearlos. La documentación es imprescindible. Entre
más completa sea la información que usted proporcione al equipo de desarrollo por medio de la
documentación y los diagramas de UML, más rápido será el desarrollo y más sólido será el sistema de
producción final.
A menudo las metodologías orientadas a objetos se enfocan en iteraciones pequeñas y rápidas de desarro-
llo, a lo que algunas veces se le conoce como el modelo de espiral. El análisis se lleva a cabo en una parte pe-
queña del sistema, en donde por lo general se empieza con un elemento de alta prioridad o tal vez con uno quewww.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 19
represente el mayor riesgo. A esto le sigue el diseño y la implementación. El ciclo se repite con el análisis de la
siguiente parte, el diseño y algo de implementación, y esto se repite hasta completar el proyecto. Es normal re-
diseñar los diagramas y los componentes mismos. El UML es una potente herramienta de modelado que puede
mejorar en forma considerable la calidad del análisis y diseño de sistemas, así como del producto final.
CÓMO ELEGIR QUÉ MÉTODO DE DESARROLLO DE SISTEMAS USAR
Las diferencias entre las tres metodologías antes descritas no son tan grandes como parecen en un principio. En
las tres metodologías, el analista necesita comprender primero a la organización (capítulo 2). Después el analista
o el equipo del proyecto necesitan elaborar un presupuesto del tiempo y los recursos necesarios para desarrollar
la propuesta del proyecto (capítulo 3). A continuación deben entrevistar a los miembros de la organización y re-
copilar información detallada mediante el uso de cuestionarios (capítulo 4), obtener muestras de los datos de los
informes existentes y observar cómo se lleva a cabo la actividad empresarial actual (capítulo 5). Las tres metodo-
logías tienen todas estas actividades en común.
Incluso los mismos métodos tienen similitudes. La metodología SDLC y la metodología orientada a objetos requie-
ren de un proceso exhaustivo de planeación y elaboración de diagramas. La metodología ágil y la metodología orien-
tada a objetos permiten crear subsistemas uno a la vez hasta que se complete todo el sistema. La metodología ágil y
la metodología SDLC se interesan por la forma lógica en que los datos se desplazan a través del sistema.
Entonces, dada la opción de desarrollar un sistema mediante el uso de una metodología SDLC, una meto-
dología ágil o una metodología orientada a objetos, ¿cuál escogería usted? La figura 1.9 muestra un conjunto de
lineamientos para ayudarlo a elegir qué método utilizar para desarrollar su siguiente sistema.
Seleccione Cuando
Metodologías ágiles
La metodología
del ciclo de vida del
desarrollo de
sistemas (SDLC)
Metodologías
orientadas
a objetos
• el cliente está satisfecho con las mejoras incrementales
• haya que desarrollar aplicaciones rápidamente en respuesta a un entorno
dinámico
• haya un defensor de proyectos de métodos ágiles en la organización
• haya que realizar un rescate (el sistema falló y no hay tiempo de averiguar
qué salió mal)
• los ejecutivos y analistas están de acuerdo con los principios de las
metodologías ágiles
• los problemas modelados se prestan a sí mismos para convertirlos en clases
• una organización ofrece apoyo para aprender UML
• es posible agregar sistemas en forma gradual, un subsistema a la vez
• la reutilización de software escrito con anterioridad es una posibilidad
• es aceptable hacer frente a los problemas difíciles primero
• los sistemas se hayan desarrollado y documentado mediante el uso de SDLC
• sea importante documentar cada paso del proceso
• sea importante la comunicación en relación con la forma en que funcionan
los nuevos sistemas
• la administración de nivel superior se sienta más cómoda o segura
si utiliza SDLC
• haya los recursos y el tiempo adecuados para completar el SDLC
completo
FIGURA 1.9
Cómo decidir qué método de
desarrollo utilizar.
Podemos considerar a la información como un recurso organi-
zado, de igual forma que consideramos a los humanos. Como tal,
se debe administrar con cuidado, al igual que los demás recursos.
La disponibilidad de poder de cómputo asequible para las orga-
nizaciones ha provocado una explosión de información y, en
consecuencia, hay que poner más atención para lidiar con la in-
formación que se genera.
Los analistas de sistemas recomiendan, diseñan y mantienen
muchos tipos de sistemas para los usuarios, incluyendo los de pro-
cesamiento de transacciones (TPS), los de automatización de ofi-
RESUMENwww.xlibros.com

20 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
E X P E R I E N C I A D E H Y P E R C A S E ® 1
“Bienvenido a Maple Ridge Engineering, mejor conocida
como MRE. Esperamos que disfrute trabajar para nosotros como
consultor de sistemas. Aunque he laborado aquí durante cinco años
en distintos puestos, me acaban de reasignar para trabajar como
ayudante administrativo de Snowden Evans, el jefe del nuevo de-
partamento de Capacitación y sistemas administrativos. Sin duda
somos un grupo diverso. Durante el recorrido de la empresa utilice
todas sus habilidades, tanto técnicas como orientadas a las perso-
nas, para intentar comprender quiénes somos e identificar los pro-
blemas y conflictos que, desde su punto de vista, debamos resolver
en relación con nuestros sistemas de información”.
“Para ponerlo al corriente, permítame decirle que Maple Ridge
Engineering es una empresa mediana de ingeniería médica. El año
pasado nuestros ingresos superaron los $287 millones. Empleamos
a cerca de 335 personas. Hay aproximadamente 150 empleados
administrativos, así como personal administrativo y de oficina como
yo; aproximadamente 75 empleados profesionales, incluyendo in-
genieros, médicos y analistas de sistemas; y cerca de 110 emplea-
dos industriales, como proyectistas y técnicos”,
“Hay cuatro oficinas. Usted nos visitará a través de HyperCase
en nuestras oficinas generales en Maple Ridge, Tennessee. Tenemos
otras tres sucursales en el sur de los Estados Unidos también:
Atlanta, Georgia; Charlotte, Carolina del Norte, y Nueva Orleans,
Louisiana. Nos gustaría tenerlo de visita cuando se encuentre cerca
del área”.
“Por ahora, debe explorar HyperCase mediante el uso de Fire-
fox, Safari o Microsoft Internet Explorer”.
“Para aprender más acerca de Maple Ridge Engineering como
empresa o averiguar cómo entrevistar a nuestros empleados, quie-
nes utilizarán los sistemas que usted diseñe, y cómo observar sus
oficinas en nuestra empresa, tal vez quiera empezar por visitar el
sitio Web en www.pearsonhighered.com/kendall. Después haga
clic en el vínculo etiquetado como HyperCase. En la pantalla de
HyperCase, haga clic en Start y estará en la recepción de Maple
Ridge Engineering. De aquí en adelante puede empezar a consultar
de inmediato”.
Este sitio Web contiene información útil sobre el proyecto, así
como archivos que puede descargar en su computadora. Hay un
conjunto de archivos de datos de Visible Analyst y otro conjunto de
archivos de datos de Visio que corresponden a HyperCase. Estos ar-
chivos contienen una serie parcialmente construida de diagramas de
flujo de datos, diagramas entidad-relación, diagramas de UML e
información del repositorio. El sitio Web de HyperCase también
contiene ejercicios adicionales. HyperCase está diseñado para ser
explorado, por lo que no debe dejar pasar ningún objeto o pista en
una página Web.
cinas (OAS), los de trabajo de conocimiento (KWS) y los de
información administrativa (MIS). También crean sistemas orien-
tados a decisiones para usuarios específicos. Entre estos sistemas
están los de soporte de decisiones (DSS), los sistemas expertos
(ES), los de soporte de decisiones en grupo (GDSS), los de trabajo
colaborativo asistido por computadora (CSCWS) y los de soporte
para ejecutivos (ESS). Muchas aplicaciones están migrando o se
están originando en la Web para ofrecer soporte para el comercio
electrónico y muchas otras funciones empresariales.
El análisis y diseño de sistemas es una metodología sistemática
para identificar problemas, oportunidades y objetivos; para analizar
los flujos de información humana y generada por computadora en
las organizaciones, y para diseñar sistemas de información compu-
tarizados para resolver un problema. Los analistas de sistemas
deben desempeñar muchos roles durante el curso de su trabajo.
Algunos de estos roles son: 1) como consultor externo para la em-
presa, 2) como experto de soporte dentro de una empresa y 3) como
agente de cambio en situaciones tanto internas como externas.
Los analistas poseen un amplio rango de habilidades. Antes
que nada el analista es un solucionador de problemas, alguien que
disfruta el reto de analizar un problema e idear una solución
funcional. Los analistas de sistemas requieren habilidades de
comunicación, que les permitan relacionarse de manera signifi-
cativa con muchos tipos de personas a diario, así como habilida-
des computacionales. Comprender a los usuarios y relacionarse
bien con ellos es imprescindible para su éxito.
Los analistas proceden de manera sistemática. El marco de
trabajo para su metodología sistemática se proporciona en lo que
se conoce como ciclo de vida del desarrollo de sistemas (SDLC).
Este ciclo de vida se puede dividir en siete fases secuenciales,
aunque en realidad las fases están interrelacionadas y a menudo
se llevan a cabo en forma simultánea. Las siete fases son: iden-
tificación de los problemas, oportunidades y objetivos; deter-
minación de los requerimientos de información del factor
humano; análisis de las necesidades del sistema; diseño del sis-
tema recomendado; desarrollo y documentación del software;
prueba y mantenimiento del sistema; e implementación y evalua-
ción del sistema.
La metodología ágil es una metodología de desarrollo de
software basada en valores, principios y prácticas básicas. Los
sistemas que se diseñan mediante métodos ágiles se pueden
desarrollar con rapidez. Las etapas en el proceso de desarrollo
ágil son exploración, planeación, iteraciones para la liberación
de la primera versión, puesta en producción y mantenimiento.
Hay una tercera metodología para el desarrollo de sistemas,
conocida como análisis y diseño orientado a objetos. Estas téc-
nicas se basan en conceptos de programación orientada a objetos
que se han codificado en el UML, un lenguaje de modelado es-
tandarizado en el que los objetos que se crean no sólo incluyen
código sobre los datos, sino también instrucciones sobre las
operaciones que se van a realizar en los datos. Los diagramas
clave ayudan a analizar, diseñar y comunicar los sistemas desa-
rrollados mediante UML. Por lo general, estos sistemas se de-
sarrollan como componentes y el proceso de replantear estos
componentes muchas veces es una actividad normal en el análi-
sis y diseño orientado a objetos.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 21
PALABRAS CLAVE Y FRASES
agente de cambio
Ajax
análisis y diseño de sistemas
análisis y diseño de sistemas orientado a objetos (O-O)
analista de sistemas
aplicaciones de comercio electrónico
arquitectura orientada a servicios (SOA)
ciclo de vida del desarrollo de sistemas (SDLC)
consultor de sistemas
diseño rápido de aplicaciones (RAD)
fase de exploración
fase de mantenimiento
fase de planeación
fase de puesta en producción
herramientas CASE
Ingeniería de Software Asistida por Computadora (CASE)
inteligencia artificial (AI)
interacción humano-computadora (HCI)
iteraciones para la liberación de la primera versión
juego de planeación
lenguaje de modelado unificado (UML)
m-Commerce, mComeerce (comercio móvil)
metodología ágil
métodos ágiles
migrar sistemas
prototipos
sistemas de automatización de oficinas (OAS)
sistemas de información administrativa (MIS)
sistemas de planificación de recursos empresariales (ERP)
sistemas de procesamiento de transacciones (TPS)
sistemas de soporte de decisiones (DSS)
sistemas de soporte de decisiones en grupo (GDSS)
sistemas de soporte para ejecutivos (ESS)
sistemas de trabajo colaborativo asistido por computadora
(CSCWS)
sistemas de trabajo de conocimiento (KWS)
sistemas expertos
software de código fuente abierto (OSS)
software hecho a la medida
PREGUNTAS DE REPASO
1. Compare los procesos de tratar la información como un recurso y tratar a los humanos como un recurso
2. Liste las diferencias entre OAS y KWS.
3. Defina el significado de MIS.
4. ¿Cuál es la diferencia entre MIS y DSS?
5. Defina el término sistemas expertos. ¿Cuál es la diferencia entre los sistemas expertos y los sistemas de soporte de
decisiones?
6. Enliste los problemas de interacción grupal para los cuales se diseñaron los sistemas de soporte de decisiones en grupo
(GDSS) y los sistemas de trabajo colaborativo asistido por computadora (CSCWS).
7. ¿Cuál es el término más general, CSCWS o GDSS? Explique.
8. Defina el término comercio-m.
9. Liste las ventajas de montar aplicaciones en la Web.
10. ¿Cuál es la razón dominante para diseñar sistemas empresariales (o ERP)?
11. Proporcione un ejemplo de un proyecto de software de código fuente abierto.
12. Liste las ventajas de utilizar las técnicas de análisis y diseño de sistemas para trabajar con los sistemas de información
computarizados para empresas.
13. Liste tres roles que el analista de sistemas debe desempeñar. Proporcione una definición para cada uno de ellos.
14. ¿Qué cualidades personales son útiles para el analista de sistemas? Haga una lista.
15. Liste y defina brevemente las siete fases del ciclo de vida del desarrollo de sistemas (SDLC).
16. ¿Para qué se utilizan las herramientas CASE?
17. ¿Cuál es la diferencia entre las herramientas CASE superiores e inferiores?
18. Defina qué significa la metodología ágil.
19. ¿Cuál es el significado de la frase “el juego de planeación”?
20. ¿Cuáles son las etapas en el desarrollo ágil?
21. Defina el término análisis y diseño orientado a objetos.
22. ¿Qué es UML?
BIBLIOGRAFÍA SELECCIONADA
Coad, P. y E. Yourdon. Object-Oriented Analysis, 2da. ed. Englewood Cliffs, NJ: Prentice Hall, 1991.
Davis, G.B. y M. H. Olson. Management Information Systems: Conceptual Foundation, Structure, and Development, 2da. ed.
Nueva York: McGraw-Hill, 1985.
Feller, J., P. Finnegan, D. Kelly y M. MacNamara. “Developing Open Source Software: A Community-Based Analysis of Re-
search”: En IFIP International Federation for Information Processing, Vol. 208, Social Inclusion: Societal and Organiza-
tional Implications for Information Systems. Editado por E. Trauth, D. Howcroft, T. Butler, B. Fitzgerald y J. DeGross, pp.
261-278. Boston: Springer, 2006.www.xlibros.com

22 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Kendall, J.E. y K. E. Kendall. “Information Delivery Systems: An Explanation of Web Push and Pull Technologies”, Commu-
nications of AIS, Vol. 1, artículo 14, abril 23, 1999.
Kendall, J.E., K.E. Kendall y S. Kong. “Improving Quality Through the Use of Agile Methods in Systems Development: People
and Values in the Quest for Quality”. En Measuring Information Systems Delivery Quality. Editado por E.W. Duggan y H.
Reichgelt, pp. 201-222. Hershey, PA: Idea Group Publishing, 2006.
Laudon, K.C. y J.P. Laudon. Management Information Systems, 11va. ed. Upper Saddle River, NJ: Pearson Prentice Hall,
2010.
Verma, S. “Software Quality and the Open Source Process”. En Measuring Information Systems Delivery Quality. Editado por
E.W. Duggan y H. Reichgelt, pp. 284-303. Hershey, PA: Idea Group Publishing, 2006.
www.visible.com/Products/index.htm. Último acceso: marzo 23, 2009.
Yourdon, E. Modern Structured Analysis Englewood Cliffs, NJ: Prentice Hall, 1989.
Zhang, P., J. Carey, D. Te’eni y M. Tremaine. “Integrating Human-Computer Interaction Development into the Systems Deve-
lopment Life Cycle: A Methodology”. Communications of the Association for Information Systems, Vol. 15, 2005, pp.
512-543.www.xlibros.com

CAPÍTULO 1 • SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO 23
E P I S O D I O 1
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Se abre el caso
En un día cálido y soleado de finales de octubre, Chip Puller estaciona su automóvil y camina hacia su oficina en la Central
Pacific University. Se sentía bien empezar como analista de sistemas y estaba esperando conocer al resto del personal.
En la oficina, Anna Liszt se presenta a sí misma. “Nos han asignado para trabajar como equipo en un nuevo proyecto. ¿Por
qué no te pongo al corriente con los detalles y después damos un paseo por las instalaciones?”
“Me parece bien”, responde Chip. “¿Cuánto tiempo llevas trabajando aquí?”
“Aproximadamente cinco años”, le responde Anna. “Empecé como analista programador pero durante los últimos años me
he dedicado al análisis y diseño. Espero que encontremos formas de aumentar nuestra productividad”, continúa Anna.
“Cuéntame sobre el nuevo proyecto”, dice Chip.
“Bien”, le responde Anna, “al igual que muchas organizaciones, tenemos una gran cantidad de microcomputadoras con
distintos paquetes de software instalados en ellas. Hasta donde sé, en la década de 1980 había pocas computadoras personales
y una colección dispersa de software. Esto se expandió con rapidez en la década de 1990 y ahora todos usan computadoras.
Algunos miembros del cuerpo docente utilizan más de una. El sistema actual que utilizamos para dar mantenimiento al software
y hardware, que en un principio era bastante útil, ahora es obsoleto y está bastante abrumado”.
“¿Qué hay sobre los usuarios? ¿A quién debo conocer? ¿Quién crees que será importante para ayudarnos con el nuevo
sistema?”, pregunta Chip.
“Vas a conocer a todos, pero hay personas clave que acabo de conocer y te diré lo que he aprendido para que las recuerdes
cuando las conozcas”.
“Dot Matricks es gerente de todos los sistemas de microcomputadoras en Central Pacific. Al parecer nos llevamos bien en
el trabajo. Es muy competente. Realmente le gustaría poder mejorar la comunicación entre los usuarios y los analistas”.
“Será un placer conocerla”, especula Chip.
“Y también está Mike Crowe, experto en mantenimiento de computadoras. Realmente parece el tipo más amable, pero está
demasiado ocupado. Necesitamos ayudar a aligerar su carga. La contraparte de Mike encargada del software es Cher Ware. Es
un espíritu libre, pero no me malentiendas: conoce su trabajo”, dice Anna.
“Tal vez sea divertido trabajar con ella”, reflexiona Chip.
“Podría ser”, asiente Anna. “También conocerás al analista financiero, Paige Prynter. Todavía no puedo entenderla bien”.
“Tal vez yo te pueda ayudar”, dice Chip.
“Por último, deberías —más bien dicho, tienes que— conocer a Hy Perteks, quien hace un excelente trabajo como encar-
gado del Centro de información. A él le gustaría que pudiéramos integrar nuestras actividades del ciclo de vida”.
“Suena prometedor”, dice Chip. “Creo que me va a gustar trabajar aquí”.
EJERCICIO
E-1. De la conversación de presentación que compartieron Chip y Anna, ¿cuáles de los elementos mencionados podrían su-
gerir el uso de herramientas CASE?www.xlibros.com

24 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
24
C A P Í T U L O 2
Comprensión y modelado de
los sistemas organizacionales
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender que las organizaciones y sus miembros son sistemas, y que como analista
debe asumir una perspectiva de sistemas.
2. Describir los sistemas en forma gráfica mediante el uso de diagramas de flujo de datos a
nivel de contexto, modelos entidad-relación, casos de uso y escenarios de casos de uso.
3. Reconocer que los distintos niveles de la administración requieren distintos sistemas.
4. Comprender que la cultura organizacional afecta al diseño de los sistemas de información.
Para analizar y diseñar sistemas de información apropiados, los analistas
de sistemas deben concebir a las organizaciones en que trabajan como
sistemas configurados por la interacción de tres fuerzas principales: los
niveles de administración, el diseño de las organizaciones y las culturas
organizacionales.
Las organizaciones son sistemas extensos compuestos por subsiste-
mas interrelacionados. Los subsistemas se ven influenciados por tres amplios niveles de perso-
nas que toman decisiones administrativas (operaciones, administración a nivel medio y
administración estratégica) y atraviesan horizontalmente todo el sistema organizacional. Las
culturas y subculturas organizacionales influyen en la forma en que las personas se interrela-
cionan en los subsistemas. Este capítulo aborda estos temas y sus implicaciones para el desa-
rrollo de sistemas de información.
LAS ORGANIZACIONES COMO SISTEMAS
Podemos conceptualizar operativamente a las organizaciones y sus miembros como sistemas
diseñados para cumplir con ciertas metas y objetivos predeterminados a través de las personas
y los recursos que emplean. Las organizaciones están compuestas por sistemas más pequeños e
interrelacionados (departamentos, unidades, divisiones, etc.) que brindan funciones especializa-
das. Algunas de las funciones comunes son contabilidad, marketing, producción, procesamiento
de datos y administración. Las funciones especializadas (sistemas más pequeños) se reintegran
en un momento dado a través de diversos medios para formar un todo organizacional efectivo.
Conceptualizar a las organizaciones como sistemas complejos permite entender la forma en
que funcionan a través de los principios de sistemas. Para establecer en forma adecuada los re-
querimientos de información y diseñar sistemas de información apropiados, es primordial com-
prender a la organización como un todo. Todos los sistemas están compuestos de subsistemas
(incluyendo los sistemas de información); por lo tanto, al estudiar una organización también de-
bemos examinar cómo se involucran los sistemas más pequeños y la manera en que funcionan.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 25
Capacidad de interrelación e interdependencia de los sistemas
Todos los sistemas y subsistemas están interrelacionados y son interdependientes. Este hecho tiene implicaciones
importantes, tanto para las organizaciones como para los analistas de sistemas que buscan ayudar a estas organi-
zaciones a cumplir mejor sus objetivos. Cuando se modifica o elimina algún elemento de un sistema, también se
afecta considerablemente al resto de los elementos y subsistemas de ese sistema.
Por ejemplo, suponga que los gerentes de una organización deciden no contratar más asistentes adminis-
trativos y desean reemplazar sus funciones mediante PC en red. Esta decisión tiene el potencial de afectar en
forma considerable no sólo a los asistentes administrativos y a los gerentes, sino también a todos los miem-
bros de la organización que construyeron redes de comunicación con los asistentes que antes trabajaban ahí.
Todos los sistemas procesan entradas provenientes de sus entornos. Por definición, los procesos cambian o
transforman las entradas en salidas. Cada vez que examine un sistema, identifique qué se está cambiando o pro-
cesando. Si no hay cambios, tal vez no esté identificando un proceso. Algunos procesos comunes en los sistemas
son verificar, actualizar e imprimir.
Otro aspecto de las organizaciones como sistemas es que todos los sistemas están contenidos por límites
que los separan de sus entornos. Los límites organizacionales existen en un rango continuo, desde los extre-
madamente permeables hasta los que son casi impermeables. Para poder adaptarse y sobrevivir, las organiza-
ciones primero deben ser capaces de importar personas, materia prima e información a través de sus límites
(entradas) y después intercambiar sus productos terminados, servicios o información con el mundo exterior
(salidas).
La retroalimentación es una forma de control de un sistema. Como sistemas, todas las organizaciones usan
la planeación y el control para administrar sus recursos con efectividad. La figura 2.1 muestra la forma en que se
utilizan las salidas del sistema como retroalimentación para comparar el rendimiento con los objetivos. A su de-
bido tiempo, esta comparación ayuda a los gerentes a formular objetivos más específicos como entradas. Veamos
el ejemplo de una empresa estadounidense de manufactura que produce conjuntos de entrenamiento con pesas
rojo, blanco y azul, y gris metálico. La empresa descubre que un año después de las olimpiadas se vendieron
muy pocos conjuntos con la combinación rojo, blanco y azul. Los gerentes de producción utilizan esa informa-
ción para tomar decisiones con respecto a los colores a producir subsecuentemente. En este caso, la retroalimen-
tación es útil para la planeación y el control.
El sistema ideal, en todo caso, es uno que se corrija o regule automáticamente de tal forma que no se requie-
ran decisiones basadas en acontecimientos comunes. Un ejemplo de ello es el sistema de cadena de suministro
para planificar la producción, el cual toma en cuenta las demandas actual y pronosticada, y formula una solución
propuesta como salida. Un fabricante italiano de ropa tejida que comercializa sus prendas en Estados Unidos
tiene un sistema así. Esta empresa produce la mayor parte de sus suéteres en color blanco, utiliza su sistema de
información de inventario computarizado para averiguar qué colores se venden más y entonces tiñe los suéteres
en esos colores justo antes de enviarlos.
La retroalimentación se recibe desde el interior de la organización y de los entornos exteriores. Cualquier
cosa externa a los límites de una organización se considera un entorno. Numerosos entornos con diversos grados
de estabilidad constituyen el medio en el que existen las organizaciones.
Algunos de éstos son: 1) el entorno de la comunidad en la que se encuentra físicamente la organización,
y se determina considerando el tamaño de su población y su perfil demográfico (nivel de educación, ingresos
promedio y otros indicadores); 2) el entorno económico, que se ve influenciado por los factores del mercado,
incluyendo la competencia; 3) el entorno político, que se controla mediante gobiernos estatales y locales,
y 4) el entorno legal, que establece leyes y lineamientos federales, estatales, regionales y locales. Aunque es
posible planear respuestas a los cambios del entorno, por lo general una organización no puede controlarlos de
manera directa.
Objetivos
Sistema
SalidasEntradas
FIGURA 2.1
Las salidas del sistema sirven
como retroalimentación para
comparar el rendimiento con los
objetivos.www.xlibros.com

26 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
El concepto de apertura o cerrazón interna de las organizaciones está relacionado y es similar al concepto de
permeabilidad de los límites externos. La apertura y cerrazón también existen en un continuo, ya que no hay tal
cosa como una organización completamente abierta o una totalmente cerrada.
La apertura se refiere al flujo libre de información dentro de la organización. Los subsistemas como los de-
partamentos creativos o artísticos a menudo se caracterizan como abiertos, con un flujo libre de ideas entre los
participantes y muy pocas restricciones en cuanto a quién recibe la información y en qué momento, cuando un
proyecto creativo está en su infancia.
En el extremo opuesto del continuo podría haber una unidad del departamento de defensa que trabaje en
un proyecto ultrasecreto de planeación que afecte la seguridad nacional. Cada persona debería entonces tener
autorización de acceso, la información oportuna sería indispensable y el acceso a la información se otorgaría
sólo a quien fuera estrictamente necesario incluir. Una unidad tal deberá funcionar bajo muchas restricciones.
Si utilizamos la superposición de sistemas para comprender a las organizaciones, podremos reconocer la
idea de que los sistemas están compuestos por subsistemas, su capacidad de interrelación e interdependen-
cia, la existencia de límites que permiten o evitan la interacción entre varios departamentos y elementos de
otros subsistemas y entornos, y la existencia de entornos internos que se caracterizan con base en un grado
de apertura y cerrazón que podría diferir entre los departamentos, las unidades o, incluso, los proyectos de
sistemas.
Organizaciones y equipos virtuales
No todas las organizaciones o partes de éstas son visibles en una ubicación física. En la actualidad, toda una
organización o varias unidades de ésta pueden poseer componentes virtuales que les permitan modificar sus
configuraciones para adaptarse a las demandas cambiantes del proyecto o del mercado. Las empresas virtuales
utilizan redes de computadoras y tecnología de comunicaciones para unir personas con habilidades específicas,
de manera que trabajen en proyectos físicamente dispersos. La tecnología de la información permite coordinar
estos equipos de miembros remotos. A menudo surgen equipos virtuales en organizaciones ya establecidas; sin
embargo, en ciertos casos las organizaciones de trabajadores remotos han podido lograr sus metas sin necesidad
de la tradicional inversión requerida para las instalaciones físicas.
O P O R T U N I D A D D E C O N S U L T O R Í A 2 . 1
La E de la vitamina E significa E-commerce (comercio electrónico)
“Nuestras tiendas de venta al público y la división de pedidos por
correo están de maravilla”, dice Bill Berry, uno de los propietarios de
Marathon Vitamin Shops, “pero para ser más competitivos debemos
establecer un sitio Web de comercio electrónico”. Su padre, copropie-
tario, responde: “Estoy de acuerdo, pero ¿dónde empezamos?” Barry
padre sabía, desde luego, que no era sólo cuestión de establecer un
sitio Web y pedir a sus clientes que enviaran por correo electrónico sus
pedidos a la tienda de ventas al público; ya había identificado ocho
elementos constitutivos del comercio electrónico y sabía que todas las
partes tenían que trabajar en conjunto dado que formaban un sistema
mayor. Para que el comercio electrónico se realizara era necesario:
1. Atraer clientes a un sitio Web de comercio electrónico.
2. Informar a los clientes sobre los productos y servicios ofrecidos.
3. Permitir a los clientes personalizar sus productos en línea.
4. Completar las transacciones con los clientes.
5. Aceptar varias formas de pago.
6. Brindar soporte a los clientes después de la venta a través del
sitio Web.
7. Hacer los arreglos correspondientes para entregar los
productos y servicios.
8. Personalizar la apariencia del sitio Web para distintos
clientes.
Bill Berry leyó la lista y la contempló por unos instantes. “Es
obvio que el comercio electrónico es más complejo de lo que pen-
saba”, dijo. Usted puede ayudar a los propietarios de Marathon
Vitamin Shops en varias formas:
1. Elabore una lista de los elementos interrelacionados o
interdependientes. Después escriba un párrafo para indicar
por qué es imprescindible supervisar estos elementos con
detenimiento.
2. Decida cuáles serán los límites y el alcance máximo del
sistema. Es decir, escriba un párrafo en el que exprese su
opinión sobre qué elementos son imprescindibles para
Marathon Vitamin Shop y cuáles se pueden explorar después.
3. Sugiera los elementos que es necesario manejar dentro de la
empresa y los que se puedan asignar a otra compañía capaz
de hacerse cargo del trabajo de una manera más eficiente.
Justifique sus sugerencias en dos párrafos, uno para las tareas
internas a la empresa y otras para las tareas que se deben
asignar a otras empresas (outsourcing).www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 27
Hay varios beneficios potenciales para las organizaciones virtuales, como la posibilidad de reducir los cos-
tos derivados de instalaciones físicas, una respuesta más rápida a las necesidades de los clientes y la capacidad
de ayudar a los empleados virtuales a cumplir con sus obligaciones familiares de criar a sus hijos o a sus padres
que están envejeciendo. Lo que aún sigue abierto a investigación y debate es qué tan importante será cumplir
con las necesidades sociales de los trabajadores virtuales. Un ejemplo de necesidad de identificación tangible con
una cultura surgió cuando ciertos estudiantes inscritos en una universidad en línea sin campus físico (ni equipos
deportivos), pedían continuamente artículos como sudaderas, tazas de café y banderines que tuvieran impreso
el logotipo de la universidad virtual. Estos artículos son artefactos culturales significativos que las escuelas con-
vencionales siempre han proporcionado a sus alumnos.
Muchos analistas de sistemas y equipos de diseño ahora pueden trabajar en forma virtual y, de hecho, mu-
chos de ellos marcaron el camino que otros tipos de empleados empezaron a seguir para realizar su trabajo en
forma virtual. Algunas aplicaciones permiten que los analistas que ofrecen asistencia técnica a través de la Web
puedan “ver” la configuración de software y hardware del usuario que solicita ayuda, con lo cual se crea un
equipo virtual ad hoc compuesto por el analista y el usuario.
Una perspectiva de sistemas
Al tomar una perspectiva de sistemas, los analistas pueden empezar a descifrar y comprender en términos gene-
rales las diversas empresas con las que entrarán en contacto. Es importante que los miembros de los subsistemas
estén conscientes de que su trabajo está interrelacionado. En la figura 2.2 podemos observar que las salidas de
los subsistemas de producción sirven como entradas para el departamento de marketing y que las salidas de éste
sirven como nuevas entradas para el de producción. Ningún subsistema puede lograr sus metas cabalmente sin
el otro.
Los problemas surgen cuando cada gerente sostiene una visión distinta de la importancia de su propio sub-
sistema funcional. En la figura 2.3 podemos ver que, de acuerdo con la perspectiva personal del gerente de mar-
keting, la empresa está controlada por el marketing y las demás áreas funcionales están interrelacionadas pero no
tienen la misma importancia. De igual forma, la perspectiva de un gerente de producción considera a su departa-
mento como el centro de la empresa que controla a todas las demás áreas funcionales.
La importancia relativa de las áreas funcionales, según lo que revelan las perspectivas personales de los ge-
rentes, adquiere un significado adicional cuando los gerentes van subiendo por los rangos hasta convertirse en
gerentes estratégicos. Pueden provocar problemas si sobreenfatizan sus requerimientos previos de información
funcional en relación con las necesidades más amplias de la organización.
Por ejemplo, si un gerente de producción sube de puesto pero sigue enfocado en los itinerarios de produc-
ción y el rendimiento de los trabajadores de la línea de producción, tal vez se vean afectados los aspectos más
amplios relacionados con los pronósticos y las políticas, por ejemplo. Esta tendencia es peligrosa en cualquier
tipo de empresa: los ingenieros que se esfuerzan por subir de puesto y se convierten en administradores de em-
presas aeroespaciales, los profesores universitarios que dejan sus departamentos para convertirse en decanos o
los programadores que avanzan y se convierten en ejecutivos de empresas de software. Con frecuencia, su res-
tringida visión periférica crea problemas para los analistas de sistemas que tratan de separar los requerimientos
reales de información de los deseos de obtener cierto tipo específico de información.
Las salidas del departamento
de marketing se convierten
en las entradas para el
departamento de producción.
Las salidas del departamento
de producción se convierten
en las entradas para el
departamento de marketing.
Marketing
Producción
FIGURA 2.2
Las salidas de un departamento
sirven como entradas para otro,
de tal forma que los subsistemas
están interrelacionados.www.xlibros.com

28 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Sistemas empresariales: considerar a la organización como un sistema
Los sistemas empresariales, que con frecuencia se denominan sistemas de planificación de recursos empresaria-
les (ERP), constituyen un término empleado para describir un sistema de información organizacional (empresa-
rial) integrado. En esencia, ERP es software que ayuda al flujo de información entre las áreas funcionales de la
organización. Es un sistema personalizado que, en vez de desarrollarlo dentro de la empresa, por lo general se
compra a una de las empresas de desarrollo de software reconocidas por sus paquetes ERP, como SAP u Oracle.
Después, el producto se personaliza para adaptarse a los requerimientos de una empresa en particular. Por lo ge-
neral, el distribuidor requiere de un compromiso con la organización en términos de capacitación especializada
para los usuarios o analistas. Muchos paquetes ERP están diseñados para operar en la Web. Aunque su populari-
dad está en aumento, hay algunos que ven a los sistemas ERP con algo de escepticismo.
El sistema ERP evolucionó a partir de la planificación de requerimientos de materiales (MRP), sistemas de
información diseñados para mejorar el proceso de manufactura en general y el proceso de ensamblaje en particu-
lar. Ahora los sistemas ERP incluyen componentes de manufactura y, por ende, ayudan con la planificación de
la capacidad, los programas de producción de materiales y los pronósticos. Además de los procesos de manu-
factura (y su contraparte representada por los servicios), los sistemas ERP incluyen la planificación de ventas y
operaciones, y la distribución, la obtención y la administración de la cadena de suministro. Por lo tanto, afecta en
forma considerable a todas las áreas de la organización, incluyendo contabilidad, finanzas, administración, mar-
keting y los sistemas de información.
Puede ser frustrante implementar una solución ERP, ya que es difícil analizar un sistema en uso y después
adaptar el modelo ERP a ese sistema. Además, las empresas tienden a diseñar sus procesos de sistemas antes
de implementar el sistema ERP. Por desgracia, es común que este proceso se realice de manera apresurada y el
modelo de negocios propuesto no siempre coincide con la funcionalidad del sistema ERP. El resultado es que se
requiere más personalización, periodos de tiempo de implementación extendidos, costos más altos y a menudo
La forma en que el gerente de marketing puede ver a la organización
La forma en que el gerente de producción puede ver a la organización C
o
m
p
r
a
s
C
o
m
p
r
a
s
F
i
n
a
n
z
a
s
P
r
o
d
u
c
c
i
ó
n
P
r
o
d
u
c
c
i
ó
n
M
a
r
k
e
t
i
n
g
M
a
r
k
e
t
i
n
g
F
i
n
a
n
z
a
s
D
i
s
t
r
i
b
u
c
i
ó
n
D
i
s
t
r
i
b
u
c
i
ó
n
FIGURA 2.3
Una descripción de la perspectiva
personal de los gerentes
funcionales muestra que
consideran que su propia área
funcional es la que controla a la
organización.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 29
se pierde la confianza del usuario. Los analistas necesitan estar conscientes de la magnitud del problema al que se
enfrentan al tratar de implementar paquetes de ERP.
DESCRIPCIÓN GRÁFICA DE LOS SISTEMAS
Podemos realizar la descripción gráfica de un sistema o subsistema, según la forma en que existe dentro de la
organización corporativa de varias formas. Los diversos modelos gráficos muestran los límites del sistema y la in-
formación que utiliza.
Los sistemas y el diagrama de flujo de datos a nivel de contexto
El primer modelo es el diagrama de flujo de datos a nivel de contexto (también conocido como modelo ambien-
tal). Los diagramas de flujo de datos se enfocan en los datos que fluyen hacia el sistema y salen de él, además
del procesamiento de estos datos. Podemos describir con detalle estos componentes básicos de todo programa
computacional y utilizarlos para analizar la precisión e integridad del sistema.
En la figura 2.4 podemos ver que el diagrama de flujo de datos a nivel de contexto emplea sólo tres sím-
bolos: 1) un rectángulo con esquinas redondas, 2) un cuadrado con dos bordes sombreados y 3) una flecha. Los
procesos transforman los datos entrantes en información de salida y el nivel de contenido tiene sólo un proceso,
que representa a todo el sistema completo. La entidad externa representa a cualquier entidad que suministra o re-
cibe información del sistema, pero que no forma parte del mismo. Esta entidad puede ser una persona, un grupo
de personas, un puesto o departamento corporativo o, inclusive, otros sistemas. Las líneas que conectan a las en-
tidades externas con el proceso se llaman flujos de datos y representan los datos.
En la figura 2.5 podemos ver un ejemplo de diagrama de flujo de datos a nivel de contexto. En este ejemplo
se representan los elementos más básicos del sistema de reservación de una aerolínea. El pasajero (una entidad)
inicia una solicitud de viaje (flujo de datos). El diagrama a nivel de contexto no muestra el suficiente detalle
como para indicar con exactitud lo que ocurre (no se supone que deba hacerlo), pero podemos ver que las pre-
ferencias del pasajero y los vuelos disponibles se envían al agente de viajes, quien a su vez envía la informa-
ción sobre los boletos de vuelta al proceso. También podemos ver que la reservación del pasajero se envía a la
aerolínea. El diagrama de flujo de datos a nivel de contexto sirve como un buen punto de inicio para dibujar el
diagrama de casos de uso (que veremos más adelante en este capítulo).
En el capítulo 7 aprenderemos que un flujo de datos contiene mucha información. Por ejemplo, la reserva-
ción del pasajero contiene su nombre, la aerolínea, el (los) número(s) de vuelo, la(s) fecha(s) del viaje, el precio,
la preferencia de asiento, etcétera. Sin embargo, por ahora debemos preocuparnos principalmente por la forma
en que un nivel de contexto define los límites del sistema. En el ejemplo anterior, sólo las reservaciones forman
parte del proceso. Otras decisiones que debe tomar la aerolínea (por ejemplo, comprar aviones, cambiar itinera-
rios, ajustar los precios) no forman parte de este sistema.
El diagrama de flujo de datos a nivel de contexto es una manera de mostrar el alcance del sistema o lo que
se va a incluir en él. Las entidades externas están fuera del alcance y esto es algo sobre lo que el sistema no tiene
control.
Un proceso significa que se llevan
a cabo una o varias acciones.
Una entidad es una persona,
grupo, departamento o cualquier
sistema que recibe o genera
información o datos.
Un flujo de datos muestra que
un proceso va a pasar o recibir
información.
FIGURA 2.4
Los símbolos básicos de un
diagrama de flujo de datos.www.xlibros.com

30 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Los sistemas y el modelo de entidad-relación
Otra forma en que un analista de sistemas puede mostrar el alcance del sistema y definir límites apropiados
para el mismo es mediante el uso de un modelo entidad-relación. Los elementos que conforman un sistema or-
ganizacional se pueden denominar entidades. Una entidad puede ser una persona, un lugar o una cosa, como un
pasajero en una aerolínea, un destino o un avión. O bien, una entidad puede ser un evento, como el fin de mes,
un periodo de ventas o el tiempo de inactividad de una máquina. Una relación es la asociación que describe a la
interacción entre las entidades.
Hay muchas convenciones para dibujar diagramas de entidad-relación (E-R) (con nombres como las nota-
ciones tipo pata de cuervo [crow’s foot], Arrow o Bachman). En este libro utilizaremos la notación tipo pata de
cuervo. Por ahora vamos a suponer que una entidad es un cuadro rectangular simple.
En la figura 2.6 aparece un diagrama de entidad-relación simple. Dos entidades se enlazan entre sí mediante
una línea. En este ejemplo, el final de la línea se marca mediante dos marcas paralelas cortas (I I) para indicar
que esta relación es de uno a uno. Por lo tanto, se asigna exactamente un empleado a una extensión telefónica.
Nadie comparte la misma extensión telefónica en esta oficina.
0
Aerolínea
Solicitud de viaje
Información
sobre los boletos
Agente
de viajes
Preferencias
y vuelos disponibles
Sistema de
reservación
de la aerolínea
Reservación
del pasajero
Pasajero
FIGURA 2.5
Un diagrama de flujo a nivel
de contexto para el sistema de
reservación de una aerolínea.
Empleado
Extensión
telefónica
Un
EMPLEADO
se asigna
a una
EXTENSIÓN
TELEFÓNICA.
Una
EXTENSIÓN
TELEFÓNICA
se enlista
para un
EMPLEADO.
se
enlista
para
se
asigna
a
FIGURA 2.6
Diagrama Entidad-Relación que
muestra una relación uno-a-uno.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 31
Las flechas rojas no forman parte del diagrama de entidad-relación; aparecen sólo para indicar cómo leerlo.
La frase del lado derecho de la línea se lee de arriba hacia abajo de la siguiente manera: “Un EMPLEADO se
asigna a una EXTENSIÓN TELEFÓNICA”. Del lado izquierdo, leyendo de abajo hacia arriba, la flecha dice:
“Una EXTENSIÓN TELEFÓNICA se enlista para un EMPLEADO”.
De manera similar, en la figura 2.7 se muestra otra relación. Es obvio que en este diagrama se utiliza la no-
tación tipo pata de cuervo (>—+), y este ejemplo específico contiene una relación de varios a uno. Si leemos de iz-
quierda a derecha, la flecha indica: “Varios EMPLEADOS son miembros de un DEPARTAMENTO”. Si leemos
de derecha a izquierda, implica: “Un DEPARTAMENTO contiene varios EMPLEADOS”.
Observe que cuando hay una relación de varios a uno, la gramática cambia de “es” a “son” aún y cuando
se escribe el “es” en singular en la línea. La notación tipo pata de cuervo y la marca individual no indican lite-
ralmente que este extremo de la relación tenga que ser de “varios” en forma obligatoria. Lo que implican es que
este extremo puede ser cualquier cosa: uno o varios.
La figura 2.8 muestra más detalles sobre este esquema. Aquí enlistamos varias relaciones de entidades comunes.
La primera, “Un EMPLEADO se asigna a una OFICINA” es una relación de uno a uno. La segunda es una relación
de uno a varios: “Una AERONAVE DE CARGA servirá a uno o más CENTROs DE DISTRIBUCIÓN”. La tercera
es ligeramente distinta, ya que tiene un círculo en un extremo. Se puede leer así: “Un ANALISTA DE SISTEMAS
se puede asignar a VARIOS PROYECTOS”, lo cual significa que el analista se puede asignar a ningún proyecto [el
círculo (O) indica cero], a uno o a varios proyectos. De igual forma, el círculo (O) indica que es posible no tener
ningún mantenimiento programado en la siguiente relación. Recuerde que la marca corta significa uno. Por lo tanto,
podemos leerlo de la siguiente forma: “Una MÁQUINA puede o no tener asignado un MANTENIMIENTO PRO-
GRAMADO”. Observe que la línea se escribe como “tiene asignado”, pero las marcas de los extremos de la línea
indican que no se va a realizar ningún mantenimiento (O) o que se va a realizar un mantenimiento (I).
La siguiente relación establece que: “Uno o más VENDEDORES (plural de VENDEDOR) se asignan a uno
o más CLIENTEs”. Ésta es la clásica relación de varios a varios. La siguiente relación se puede leer así: “La
OFICINA PRINCIPAL puede tener uno o varios EMPLEADOs”, o “Uno o más EMPLEADOs pueden asignarse
o no a la OFICINA PRINCIPAL”. Una vez más, los símbolos I y O juntos implican una situación booleana; en
otras palabras, uno o cero.
La relación final que se muestra en esta figura se puede leer así: “Varios PASAJEROs van a volar a varios
DESTINOs”. Algunas personas prefieren usar este símbolo [>—+] para indicar una condición de “varios” obliga-
toria (¿sería posible tener sólo un pasajero o sólo un destino?). Aún así, algunas herramientas CASE como Vi-
sible Analyst no ofrecen esta posibilidad, ya que es suficiente con la condición opcional de uno o varios que se
muestra en la relación VENDEDOR-CLIENTE.
Hasta ahora hemos modelado todas nuestras relaciones mediante un solo rectángulo simple y una línea. Este
método funciona bien cuando examinamos las relaciones de cosas reales, como personas, lugares y cosas. Pero
Departamento
es miembro de
contiene
Empleado
Varios EMPLEADOS
son miembros de un
DEPARTAMENTO.
Un DEPARTAMENTO
contiene varios
EMPLEADOS.
FIGURA 2.7
Un diagrama de entidad-relación
que muestra una relación de varios
a uno.www.xlibros.com

32 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
algunas veces creamos elementos en el proceso de desarrollo de un sistema de información. Algunos ejemplos
son facturas, recibos, archivos y bases de datos. Por ejemplo, cuando queremos describir la forma en que se rela-
ciona una persona con un recibo, es conveniente indicar el recibo de una manera distinta, como se muestra en la
figura 2.9, en forma de entidad asociativa.
Una entidad asociativa puede existir sólo si está conectada con por lo menos otras dos entidades. Por esta
razón algunos la llaman gerundio, cruce, intersección o entidad concatenada. Esta formulación tiene sentido, ya
que un recibo no sería necesario a menos que hubiera un cliente y un vendedor para realizar la transacción.
La entidad atributiva es otro tipo de entidad. Cuando un analista quiere mostrar datos que dependen por com-
pleto de la existencia de una entidad fundamental, hay que utilizar una entidad atributiva. Por ejemplo, si una bi-
craft
Pasajero Destino
se asigna a
es ocupada por
es asignado a
será desarrollado por
está bajo
se está realizando en
se asigna a
es llamado por
tiene
se asigna a
va a volar a
será visitado por
servirá a
es servido por
Empleado Oficina
Analista de
sistemas
Centro de
distribución
Vendedor Cliente
Oficina principal Empleado
Máquina
Proyecto
Aeronave
de carga
Mantenimiento
programado
FIGURA 2.8
En los diagramas E-R se utilizan
tres tipos distintos de entidades.
Entidad
fundamental
Entidad
asociativa
Por lo general una entidad real:
una persona, lugar o cosa
Algo creado que une
a dos entidades
Algo útil para describir atributos,
en especial los grupos repetitivos
Entidad
atributiva
FIGURA 2.9
Tres tipos diferentes de entidades
utilizadas en diagramas E-Rwww.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 33
blioteca tiene varias copias del mismo libro, se puede utilizar una entidad atributiva para designar qué copia del
libro se va a sacar. La entidad atributiva es útil para mostrar grupos de datos repetitivos. Por ejemplo, suponga que
vamos a modelar las relaciones que existen cuando un patrocinador obtiene boletos para un concierto o show. Al
principio las entidades parecen obvias: “Un CLIENTE y un CONCIERTO/SHOW”, como se muestra en la figura
2.10. ¿Qué tipo de relación existe? A primera instancia, el CLIENTE obtiene una reservación para un CON-
CIERTO/SHOW y se puede decir que el CONCIERTO/SHOW hizo una reservación para un CLIENTE .
Desde luego que el proceso no es tan simple, por lo que el diagrama E-R tampoco necesita ser así de simple.
En realidad el CLIENTE hace una RESERVACIÓN, como se muestra en la figura 2.11. La RESERVACIÓN es
para un CONCIERTO/SHOW. El CONCIERTO/SHOW contiene la RESERVACIÓN y la RESERVACIÓN está
a nombre del CLIENTE. Agregamos una entidad asociativa en este caso ya que se creó una RESERVACIÓN de-
bido a que el sistema de información requiere que se relacionen el CLIENTE y el CONCIERTO/SHOW.
Cliente
Concierto/Show
hace una
reservación
para
obtiene
una
reservación
para
Aquí va
mi primer
intento.
Ken
FIGURA 2.10
El primer intento para dibujar un
diagrama E-R.
Concierto/Show
hace
Cliente
está a
nombre
de
es
para un
Agregué
una entidad
asociativa.
Julie
tiene
Reservación
FIGURA 2.11
Cómo mejorar el diagrama E-R al
agregar una entidad asociativa
llamada RESERVACIÓN.www.xlibros.com

34 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Podemos ver de nuevo que este proceso es bastante simple, pero como los conciertos y shows tienen varias
presentaciones, en la figura 2.12 dibujamos una vez más el diagrama E-R. Ahora agregamos una entidad atribu-
tiva para manejar las diversas presentaciones del CONCIERTO/SHOW. En este caso se hace la RESERVACIÓN
para una PRESENTACIÓN específica y la PRESENTACIÓN es una de varias que pertenecen a un CONCIERTO/
SHOW específico. A su vez, el CONCIERTO/SHOW tiene varias presentaciones y una PRESENTACIÓN tiene
una RESERVACIÓN que está a nombre de un CLIENTE específico.
A la derecha de este diagrama E-R hay un conjunto de atributos de datos que conforman cada una de las en-
tidades. Algunas entidades pueden tener atributos en común. Es posible realizar búsquedas con los atributos que
están subrayados. Los atributos se denominan claves y los describiremos en el capítulo 13.
A menudo los diseñadores de sistemas utilizan diagramas E-R para ayudar a modelar el archivo o la base de
datos. Sin embargo, es aun más importante que el analista de sistemas comprenda lo más pronto posible tanto
las entidades como las relaciones en el sistema organizacional. Al realizar bosquejos de algunos diagramas E-R
básicos, el analista necesita:
1. Enlistar las entidades en la organización para obtener una mejor comprensión de la misma.
2. Elegir las entidades clave para reducir el alcance del problema a una dimensión manejable y significativa.
Concierto/Show
tiene
tiene pertenece a
Presentación
hace
Cliente
Reservación
está
a nombre
de
se
hace
para
Cliente-nombre
Cliente-dirección
Cliente-teléfono
Cliente-tarjeta-de-crédito
Reservación-número
Cliente-nombre
Presentación-número
Concierto/Show
Fecha
Hora
Ubicación
Precio
Presentación-número
Concierto/Show
Fecha
Hora
Ubicación
Precio-opciones
Concierto/Show
Concierto-detalles
Fechas-del-evento
Ubicación
FIGURA 2.12
Un diagrama E-R más completo
que muestra los atributos de datos
de las entidades.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 35
3. Identificar cuál debe ser la entidad principal.
4. Confirmar los resultados de los pasos 1 al 3 por medio de otros métodos de recopilación de datos
(investigación, entrevistas, administración de cuestionarios, observación y prototipos), según lo descrito en
los capítulos 4 al 6.
Es imprescindible que el analista de sistemas empiece a dibujar diagramas E-R al entrar a la organización en
vez de esperar a que sea necesario diseñar la base de datos, ya que los diagramas E-R ayudan al analista a com-
prender cuál es la verdadera actividad de la organización, a determinar el tamaño y alcance del problema, y a discernir
si está tratando o no con el problema correcto. Hay que confirmar o revisar los diagramas E-R a medida que se
lleve a cabo el proceso de recopilación de datos.
MODELADO DE CASOS DE USO
Aunque en un principio se presentaron como un diagrama para usarlo en el UML orientado a objetos, ahora los
casos de uso se utilizan sin importar la metodología para el desarrollo de sistemas. Se pueden utilizar como parte
del SDLC o en el modelado ágil. Un modelo de caso de uso describe qué hace un sistema sin describir cómo lo
A T R A C T I V O D E L A M A C
Microsoft Visio facilita al analista de sistemas la tarea de dibujar diagramas E-R, así como la mayoría de los diagramas
que se encuentran en este libro, pero está disponible sólo para PC. Los usuarios de equipos Mac tienen una alternativa:
OmniGraffle Professional. Este paquete de software es más fácil de usar que Microsoft Visio, ya que su interfaz es
más uniforme e intuitiva, y se opera arrastrando y colocando.
También incluye una “guía inteligente” que utiliza marcadores de distancia desplegables para ayudar a colocar
los símbolos en los lugares correctos. OmniGraffle tiene integrados muchos símbolos como los que se utilizan en los
diagramas E-R, pero también permite al usuario acceder a una biblioteca de terceros conocida como Graffletopia
para buscar símbolos de UML y otros especializados.
FIGURA 2.MAC
OmniGraffle de Omni Group es un paquete de dibujo poderoso y fácil de usar.www.xlibros.com

36 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
hace; es decir, es un modelo lógico del sistema (en el capítulo 7 veremos más detalles sobre los modelos lógi-
cos o conceptuales). El modelo de caso de uso presenta al sistema desde la perspectiva de un usuario fuera del
mismo (por ejemplo, los requerimientos del sistema).
Un analista desarrolla casos de uso en un esfuerzo de cooperación con los expertos de negocios que ayudan
a definir los requerimientos del sistema. El modelo de caso de uso provee un medio efectivo de comunicación
entre el equipo de negocios y el equipo de desarrollo. Un modelo de caso de uso particiona la forma en que tra-
baja el sistema en comportamientos, servicios y respuestas (los casos de uso) que sean importantes para los usua-
rios del sistema.
Desde la perspectiva de un actor (o usuario), un caso de uso debe producir algo de valor. Por lo tanto, el ana-
lista debe determinar qué es importante para el usuario y debe recordar incluirlo en el diagrama del caso de uso.
Por ejemplo, ¿introducir una contraseña es algo de valor para el usuario? Tal vez se deba incluir si al usuario le
preocupa la seguridad o si es algo imprescindible para el éxito del proyecto.
Símbolos de los casos de uso
Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso, junto con líneas conectoras. Los
actores son similares a las entidades externas; existen fuera del sistema. El término actor se refiere a un rol
específico de un usuario del sistema. Por ejemplo, un actor puede ser un empleado, pero también puede ser un
cliente en la tienda de la empresa. Incluso cuando es la misma persona en el mundo real, se representa como dos
símbolos distintos en un diagrama de caso de uso, ya que la persona interactúa con el sistema en distintos roles.
El actor existe fuera del sistema e interactúa con éste de una manera específica. Un actor puede ser un humano,
otro sistema o un dispositivo como un teclado o una conexión Web. Los actores pueden iniciar una instancia de
un caso de uso. Un actor puede interactuar con uno o más casos de uso; un caso de uso puede involucrar a uno
o más actores.
Los actores se pueden dividir en grupos. Los actores principales suministran datos o reciben información
del sistema. Algunos usuarios interactúan en forma directa con el sistema (actores del sistema), pero los actores
principales también pueden ser personas de negocios que no interactúen directamente con el sistema sino que
participen en cierta forma. Los actores principales son importantes ya que son las personas que usan el sistema
y pueden proveer los detalles acerca de lo que debería hacer el caso de uso. También pueden proveer una lista
de objetivos y prioridades. Los actores de soporte (también conocidos como actores secundarios) ayudan a man-
tener el sistema en funcionamiento o a proveer otros servicios; son las personas que operan el departamento de
soporte técnico, los analistas, los programadores, etcétera.
Algunas veces es conveniente crear un perfil de actor que enliste a los actores, su historial y sus habilidades
en un formato de tabla. Esto puede ser útil para entender cómo interactúa el actor con el sistema. Por ejemplo, el
perfil del Especialista de procesamiento de pedidos sería: “Un usuario rutinario del software, familiarizado con
las características menores, las excepciones de los pedidos y la personalización de pedidos”. También es conve-
niente hacer una lista de los actores junto con sus objetivos y prioridades. Cada objetivo se puede convertir en
un caso de uso.
Un caso de uso provee a los desarrolladores una perspectiva de lo que quieren los usuarios, sin detalles téc-
nicos o implementación. Podemos considerar un caso de uso como una secuencia de transacciones en un sistema.
El modelo de casos de uso se basa en las interacciones y relaciones de casos de uso individuales.
Un caso de uso siempre describe tres cosas: un actor que inicia un evento, el evento que desencadena un
caso de uso y el caso de uso que realiza las acciones desencadenado por el evento. En un caso de uso, un actor
que utiliza el sistema inicia un evento que comienza una serie relacionada de interacciones en el sistema. Los ca-
sos de uso se utilizan para documentar una transacción o evento únicos. Un evento es una entrada para el sistema
que ocurre a una hora y lugar específicos, y provoca que el sistema haga algo.
Es mejor crear menos casos de uso que un exceso de ellos. A menudo no se incluyen las consultas y los in-
formes; 20 casos de uso (y no más de 40 o 50) son suficientes para un sistema grande. Los casos de uso también
se pueden anidar, si es necesario. Algunos casos de uso utilizan el verbo administrar para agrupar casos de uso
de manera que se puedan agregar, eliminar y cambiar a otro diagrama de casos de uso de menor nivel. Usted
puede incluir un caso de uso en varios diagramas, pero el verdadero caso de uso está definido sólo una vez en el
repositorio. El nombre de un caso de uso consta de un verbo y un sustantivo.
Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de comportamiento y se utilizan principalmente en los diagra-
mas de casos de uso. Hay cuatro tipos básicos de relaciones de comportamiento: comunica, incluye, extiende y
generaliza. Observe que todos estos términos son verbos. En la figura 2.13 se muestran las flechas y líneas quewww.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 37
se utilizan para dibujar diagramas de cada uno de los cuatro tipos de relaciones de comportamiento. A continua-
ción describiremos estas cuatro relaciones.
COMUNICACIÓN Esta relación de comportamiento se utiliza para conectar un actor con un caso de uso. Recuerde
que la tarea del caso de uso es proporcionar cierto tipo de resultado que sea benéfico para el actor en el sistema.
Por lo tanto, es importante documentar estas relaciones entre los actores y los casos de uso. En nuestro primer
ejemplo, un Estudiante se comunica con Inscribir en el curso. En los diagramas de casos de uso de la figura
2.14 se muestran ejemplos de algunos componentes de un ejemplo de inscripción de estudiantes.
INCLUSIÓN Esta relación (también conocida como relación de usos) describe la situación en la que un caso de
uso contiene comportamiento común para más de un caso de uso. En otras palabras, el caso de uso común
se incluye en los otros casos de uso. Una flecha punteada que apunta al caso de uso común indica la relación de
inclusión. Un ejemplo sería un caso de uso Pagar cuotas de estudiantes que se incluye en Inscribir en el curso
y Hacer arreglos de hospedaje, ya que en ambos casos los estudiantes deben pagar sus cuotas. Varios casos de
uso pueden usar esto. La flecha apunta hacia el caso de uso común.
Relación
Comunica
Incluye
Símbolo
Para conectar un actor con un caso de uso se utiliza una línea
sin puntas de flecha.
Un caso de uso contiene un comportamiento común para
más de un caso de uso. La flecha apunta al caso de uso
común.
Generaliza Una “cosa” de UML es más general que otra “cosa”.
La flecha apunta a la “cosa” general.
Extiende Un caso de uso distinto maneja las excepciones del caso
de uso básico. La flecha apunta del caso de uso extendido
al básico.
Significado
<< Incluye >>
<< Extiende >>
FIGURA 2.13
Algunos componentes
de los diagramas de
caso de uso que
muestran a los actores,
los casos de uso y las
relaciones para un
ejemplo de inscripción
de estudiantes.
<< incluye >>
<< incluye >>
Inscribir
en el curso
Relación
de inclusión
Hacer arreglos
de hospedaje
Pagar cuotas
de estudiantes
<< extiende >> Pagar cuotas
de estudiantes
Relación
de extensión
el estudiante indica el
tipo de cobertura
Seguro médico
de estudiantes
Relación de
comunicación
Inscribir
en el
curso
Estudiante
Estudiante de
medio tiempo
Estudiante
Relación de
generalización
FIGURA 2.14
Ejemplos de casos de uso y
relaciones de comportamiento
para la inscripción de estudiantes.www.xlibros.com

38 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
EXTENSIÓN Esta relación describe la situación en la que un caso de uso posee el comportamiento que permite al
nuevo caso de uso manejar una variación o excepción a partir del caso de uso básico. Por ejemplo, el caso de uso
extendido Seguro médico de estudiantes extiende el caso de uso básico Pagar cuotas de estudiantes. La flecha
va del caso de uso extendido al caso de uso básico.
GENERALIZACIÓN Esta relación implica que una cosa es más común que otra. Esta relación puede existir entre
dos actores o dos casos de uso. Por ejemplo, un Estudiante de medio tiempo generaliza a un Estudiante.
De manera similar, algunos de los empleados de la universidad son profesores. La flecha apunta a la cosa
general.
Desarrollo del alcance del sistema
El alcance de un sistema define sus límites, lo que está al alcance (dentro del sistema) y lo que está fuera de él.
Por lo general el proyecto cuenta con un presupuesto que ayuda a definir el alcance, además del tiempo inicial
y final. Los actores siempre están fuera del alcance del sistema. Las líneas de comunicación que conectan a los
actores con los casos de uso son los límites y definen el alcance. Como un diagrama de caso de uso se crea du-
rante las primeras etapas del ciclo de vida de los sistemas, el presupuesto, tiempo inicial y final pueden cambiar
a medida que avanza el proyecto; a medida que el analista aprende más sobre el sistema, tal vez cambien los
diagramas del caso de uso, el caso de uso y el alcance.
Desarrollo de diagramas de casos de uso
El caso de uso principal consiste en un flujo estándar de eventos que describe un comportamiento estándar del
sistema. El caso de uso principal representa la terminación normal, esperada y exitosa del caso de uso.
Para crear un diagrama de un caso de uso, empiece por pedir a los usuarios una lista de todo lo que el sis-
tema deba hacer por ellos. Esto se puede realizar mediante entrevistas, en una sesión de diseño de aplicación
conjunta (como se describe en el capítulo 4) o a través de otras sesiones guiadas en equipo. El analista también
puede utilizar sesiones de historias ágiles (que describiremos en el capítulo 6) para desarrollar casos de uso.
Anote quién está involucrado con cada caso de uso y las responsabilidades o servicios que el caso de uso debe
proveer a los actores o a los otros sistemas. En las fases iniciales, ésta puede ser una lista parcial que se expanda
en las fases de análisis posteriores. Use los siguientes lineamientos:
1. Revise las especificaciones de negocios e identifique a los actores involucrados.
2. Identifique los eventos de alto nivel y desarrolle los casos de uso principales que describen a esos eventos
junto con la forma en que los actores los inician. Examine con cuidado los roles que desempeñan los actores
para identificar todos los posibles casos de uso principales iniciados por cada actor. No necesita mostrar los
casos de uso que tengan poca o nula interacción del usuario.
3. Revise cada caso de uso principal para determinar las posibles variaciones del flujo a través del caso de uso.
Con base en este análisis establezca las rutas alternativas. Debido a que generalmente el flujo de eventos es
distinto en cada caso, busque actividades que podrían tener éxito o fracasar. Busque además las
ramificaciones en la lógica del caso de uso en donde sea posible obtener distintos resultados.
Un diagrama de flujo de datos a nivel de contexto puede ser un punto de partida para un caso de uso. Las en-
tidades externas son los actores potenciales. Después examine el flujo de datos para determinar si podría iniciar
un caso de uso o si podría ser producido por uno.
En la figura 2.15 se muestra un ejemplo de un diagrama de caso de uso que representa a un sistema utilizado
para planear una conferencia. Los actores son el Presidente de la conferencia, responsable de planearla y admi-
nistrarla, el Participante de la conferencia, los Oradores, un Orador principal, Reservaciones de hotel y un
Proveedor de alimentos. Los actores representan el rol que desempeña el usuario y el Proveedor de alimentos
puede ser un empleado del hotel o un servicio de banquetes externo.
Tanto el Presidente de la conferencia como el Proveedor de alimentos están involucrados en la planea-
ción de las comidas y los banquetes. El Presidente de la conferencia también es responsable de organizar
a los oradores. El Participante se registra para la conferencia. Observe que el caso de uso Reservar cuarto
está involucrado en una relación de inclusión con los casos de uso Organizar orador y Registrarse para la
conferencia, ya que tanto los oradores como los participantes necesitarán alojamiento. El caso de uso Orga-
nizar la traducción de idiomas extiende al caso de uso Registrarse para la conferencia ya que no todos los
participantes requerirán servicios de traducción de idiomas. El actor Orador es una generalización de Orador
principal.
Desarrollo de escenarios de casos de uso
Cada caso de uso tiene una descripción. Designaremos a la descripción como un escenario de caso de uso. Como
dijimos antes, el caso de uso principal representa el flujo estándar de eventos en el sistema y las rutas alternativaswww.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 39
describen variaciones sobre el comportamiento. Los escenarios de casos de uso pueden describir lo que ocurre al
comprar un artículo agotado, o si una empresa de tarjetas de crédito rechaza la compra solicitada por un cliente.
No hay un formato estandarizado para los casos de uso, por lo que cada organización tiene que especificar
los estándares a incluir. A menudo, los casos de uso se documentan mediante una plantilla de documento de caso
de uso predeterminada por la organización, que facilita la lectura de los casos de uso y provee información estan-
darizada para cada caso de uso en el modelo.
Niveles de los casos de uso
Tal vez quiera crear casos de uso para distintos niveles. Hay un método (definido por Alistair Cockburn) que
utiliza las siguientes metáforas de altitud:
1. Blanco es el nivel más alto, al igual que las nubes. Éste es el nivel empresarial y puede haber sólo cuatro o
cinco para toda la organización. Algunos ejemplos podrían ser anunciar los productos, vender los productos
a los clientes, administrar el inventario, administrar la cadena de suministro y optimizar los embarques.
2. El cometa es inferior al blanco, pero sigue siendo un nivel alto que ofrece una visión general. El caso de uso
del cometa puede estar en el nivel de unidad de negocio o de departamento, y es un resumen de los
objetivos. Algunos ejemplos serían registrar estudiantes o, si se trabaja con una agencia de viajes, hacer la
reservación de aerolínea, hotel, automóvil o crucero.
3. Azul está a nivel del mar, y por lo general se crea para los objetivos de los usuarios. A menudo ofrece el
mayor interés para los usuarios y es más fácil de comprender para los negocios. Por lo general se escribe
para una actividad de negocios y cada persona debe ser capaz de realizar una actividad de nivel azul en un
Proveedor
de alimentos
Presidente
de la
conferencia
Reservaciones
de hotel
Organizar
orador
Planear
la provisión
de alimentos
<< incluye >>
Reservar
cuarto<< incluye >>
<< extiende>>
Participante
Registrarse
para la conferencia
Orador
principal
Orador
Organizar la
traducción
de idiomas
FIGURA 2.15
Un diagrama de caso de uso que
representa al sistema utilizado
para planear una conferencia.www.xlibros.com

40 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
lapso de 2 a 20 minutos. Algunos ejemplos son registrar un estudiante que desea continuar, agregar un nuevo
cliente, colocar un artículo en un carrito de compras y pasar a pagar.
4. Índigo o pez es un caso de uso que muestra muchos detalles, a menudo a un nivel funcional o subfuncional.
Algunos ejemplos son elegir una clase, pagar las cuotas académicas, buscar el código de aeropuerto para una
ciudad y producir una lista de clientes después de introducir un nombre.
5. Negro o almeja, como en el fondo del océano. Éstos son los casos de uso más detallados, a un nivel de sub-
función. Algunos ejemplos podrían ser validar un inicio de sesión seguro, agregar un nuevo campo mediante
HTML dinámico o usar Ajax para realizar una pequeña parte de una página Web.
En la figura 2.16 se muestra un ejemplo de escenario de caso de uso. Algunas de las áreas que se incluyen
son opcionales y tal vez no todas las organizaciones las utilicen. Las tres áreas principales son:
1. Un encabezado de área que contiene los identificadores e iniciadores del caso.
2. Los pasos realizados.
3. Un área de pie de página que contiene precondiciones, suposiciones, preguntas y demás información relacionada.
Nombre del caso de uso: Registrarse para la conferencia ID Único: Conf RG 003
Área:
Actor(es):
Descripción:
Evento desencadenador:
Precondiciones:
Postcondiciones:
Suposiciones:
Pasos realizados (ruta principal)
Planeación de la conferencia
El participante ya se registró y creó una cuenta de usuario.
El participante tiene un navegador Web, además de un ID de usuario y contraseña válidos.
El participante se registró con éxito para la conferencia.
Garantía de éxito: El participante se registró para la conferencia y está inscrito en todas las sesiones seleccionadas.
Garantía mínima: El participante pudo iniciar sesión.
Requerimientos cumplidos: Permitir que los participantes de la conferencia se registren mediante un sitio Web seguro.
Cuestiones pendientes: ¿Cómo se debe manejar una tarjeta de crédito rechazada?
Prioridad: Alta
Riesgo: Medio
El participante utiliza el sitio Web de registro para la conferencia, introduce su ID de usuario y su contraseña,
y hace clic en el botón de inicio de sesión.
1. El participante inicia sesión mediante el servidor Web seguro.
2. Se lee el registro del participante y se verifica su contraseña.
3. Se muestra la información del participante y la sesión
en la página Web de registro.
4. El participante introduce su información en el formulario
Web de registro y hace clic en el botón Enviar.
5. Se valida la información de registro en el servidor Web.
6. Se muestra la página Confirmación de registro para confirmar
la información de registro.
7. Se hace un cargo a la tarjeta de crédito equivalente
a las cuotas de registro.
8. Se escribe el registro en el Diario de agregar registros.
ID de usuario, contraseña
Registro del participante, ID de usuario, contraseña
Registro del participante, registro de la sesión
Formulario Web de registro
Formulario Web de registro
Página Web de confirmación
Página Web segura para tarjeta de crédito
Página Web de confirmación
9. Se actualiza el registro en el Archivo maestro de registros. Página Web de confirmación, registro del proceso de registro
10. Se actualiza el registro de la sesión para cada sesión
seleccionada en el Archivo maestro de sesiones.
Página Web de confirmación, registro de la sesión
11. Se actualiza el registro para el participante en el Archivo
maestro de participantes.
Página Web de confirmación, registro de participantes
12. Se envía la página Web de Confirmación de registro exitoso
al participante.
Número de confirmación del registro en el proceso de registro
Tipo de desencadenador:
Participante
Interesados: Patrocinador de la conferencia, oradores de la conferencia
Nivel: Azul
Permitir que el participante de la conferencia se registre en línea mediante un sitio Web seguro.
Información para los pasos
Externo Temporal
FIGURA 2.16
Un escenario de caso de uso se
divide en tres secciones:
identificación e iniciación; pasos
realizados; y condiciones,
suposiciones y preguntas.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 41
La primer área (identificadores e iniciadores del caso de uso) orienta al lector y contiene el nombre del
caso de uso junto con un ID único: el área de aplicación o sistema al que pertenece este caso de uso; los actores
involucrados en el caso de uso; y los interesados que tienen un alto nivel de interés en el caso de uso. Algunos
interesados nunca interactúan en forma directa con el sistema, como los accionistas, el consejo de directores o el
gerente de ventas. Cada actor principal es un interesado, pero no se enlista en el área de interesados. Se incluye
el nivel (azul, cometa, etc.) y una breve descripción de lo que logra el caso de uso.
El encabezado concluye con el evento iniciador (desencadenador); es decir, lo que ocasionó que empezara
el caso de uso, junto con el tipo de desencadenador, ya sea externo o temporal. Los eventos externos son los
que inicia un actor, ya sea una persona u otro sistema que solicita información, como el sistema de reserva-
ciones de una aerolínea que solicita información sobre los vuelos de un sistema de aerolíneas. Los eventos
temporales son aquellos que se desencadenan o empiezan debido al tiempo. Hay eventos que ocurren a una
hora específica, como enviar correo electrónico sobre ofertas especiales una vez a la semana los domingos en
la tarde, enviar facturas en un día específico o generar estadísticas gubernamentales en una fecha especificada
cada trimestre.
La segunda área del caso de uso incluye los pasos realizados y la información requerida para cada uno de
ellos. Estos enunciados representan el flujo estándar de eventos y los pasos que se llevaron a cabo para completar
con éxito el caso de uso. Es conveniente escribir un caso de uso para la ruta principal y después escribir uno para
cada una de las rutas alternativas por separado, en vez de utilizar instrucciones IF...THEN. Los pasos se enume-
ran con un entero y pueden provenir de una entrevista detallada con los usuarios, o se pueden derivar de historias
de modelado ágil (como veremos en el capítulo 6). Hay que revisar estos pasos con los usuarios para aclarar todo
el proceso.
El analista debe examinar cada uno de los pasos y determinar la información requerida para cada uno. Si
no puede determinar la información, debe programar una entrevista de seguimiento con el usuario. Algunas des-
cripciones de casos de uso incluyen extensiones o escenarios alternativos, con las excepciones como secciones
adicionales que siguen el flujo estándar de eventos. Éstas se enumeran con un entero, un punto decimal y otro
entero, como 3.1, 3.2, 3.3, etcétera (estos pasos pueden o no utilizarse). Los analistas y los usuarios pueden orga-
nizar lluvias de ideas para ver qué puede fallar en la ruta principal y tal vez para descubrir detalles y condiciones
importantes. Es necesario trabajar con los usuarios para determinar qué hacer cuando ocurran estas condiciones.
Esto ayuda a detectar errores en las primeras etapas del ciclo de vida.
La figura 2.17 muestra cómo se pueden incluir escenarios lógicos y alternativos en la sección intermedia de
un caso de uso. En este ejemplo de la aerolínea podemos observar que el paso 1 está compuesto de pasos más pe-
queños, a muchos de los cuales se les antepone un “si”. Estos pasos siguen en la ruta principal, pero ocurren sólo
si se cumple la condición. Por ejemplo, si hay muchos aeropuertos que dan servicio a una cuidad, entonces se
mostrarán todos los aeropuertos. Aquí también pueden aparecer las extensiones o escenarios alternos. Para esta
aerolínea, otros escenarios incluyen la selección de vuelos, la selección de asientos y la selección de comidas.
Los casos de uso pueden incluir también pasos iterativos o de ciclos.
La tercera área del caso de uso incluye:
Precondiciones, o la condición del sistema antes de que se pueda llevar a cabo el caso de uso, que puede ser
otro caso de uso. Un ejemplo podría ser, “El espectador inició sesión con éxito en el sistema”, o podría ser la
terminación exitosa de otro caso de uso.
Postcondiciones, o el estado del sistema después de que termine el caso de uso, incluyendo los resultados
que recibieron las personas, las transmisiones a otros sistemas y los datos que se hayan creado o
actualizado. Las postcondiciones se relacionan con los objetivos o requerimientos de los usuarios a partir
de una definición del problema (como veremos en el capítulo 3) o de historias ágiles (como veremos en el
capítulo 6).
Las suposiciones que podrían afectar al método del caso de uso y que podrían estipular la tecnología
requerida, como los requerimientos mínimos de tecnología en un navegador Web o incluso una versión
específica o más reciente del mismo. Una suposición podría ser que estén habilitadas las cookies o el
JavaScript. El analista debe determinar qué hacer si no se cumplen las suposiciones. Al usar Google Maps,
el navegador Web debe tener habilitado el JavaScript. Si no está habilitado, el mapa no se mostrará. Netflix
requiere el uso de cookies. Las buenas páginas Web detectarán que no se ha cumplido una suposición y lo
notificarán al espectador mediante un mensaje, incluyendo la información sobre cómo activar las cookies o
el JavaScript para los distintos navegadores Web.
La garantía mínima es el mínimo que se prometió a los usuarios. Tal vez ellos no estén contentos con este
resultado y puede ser que no ocurra nada.
La garantía de éxito es lo que dejaría a los usuarios satisfechos: por lo general, que se haya cumplido el
objetivo del caso de uso.
Hay que atender cualquier cuestión o responder pregunta pendiente antes de implementar el caso de uso.www.xlibros.com

42 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Una declaración opcional de prioridad del caso de uso, que puede provenir de una definición del problema o
de los requerimientos de los usuarios.
Una declaración opcional del riesgo involucrado al crear el caso de uso.
El área “requerimientos cumplidos” enlaza el caso de uso con los requerimientos u objetivos del usuario a
partir de una definición del problema. Una vez que desarrolle los casos de uso, asegúrese de repasar sus resulta-
dos con los expertos de negocios para verificar y refinar los casos de uso si es necesario.
En este escenario de caso de uso específico llamado Registrarse para la conferencia, el único actor invo-
lucrado es el Participante. El área general es Planeación de la conferencia y el caso de uso se desencadena
debido al inicio de sesión del participante en la página Web de registro. El área Pasos realizados muestra
una lista de la secuencia de eventos que deben ocurrir para un registro exitoso en la conferencia. Observe que la infor-
mación necesaria para realizar cada uno de los pasos se muestra del lado derecho, y puede incluir páginas Web y
formularios, tablas y registros de las bases de datos.
Pasos realizados (ruta principal) Información para los pasos
1. Introducir aeropuertos de salida y llegada, fechas del viaje Ubicaciones de los aeropuertos
1.1. Si se introduce el código de un aeropuerto, mostrar el nombre, ciudad y país que coincidan
1.2. Si se introduce una ciudad, encontrar todas las ciudades que coincidan
1.3. El cliente selecciona una ciudad.
1.4. Si hay más de un aeropuerto para la ciudad, mostrar los aeropuertos
1.5. El cliente selecciona un aeropuerto
1.6. Insertar el código del aeropuerto (3 caracteres)
1.7. Mostrar el país, ciudad y nombre del aeropuerto que coincida
2. Buscar todos los vuelos que coincidan con asientos disponibles Información de los vuelos
3. El cliente selecciona un vuelo
4. El cliente inicia sesión Inicio de sesión del cliente
5. El cliente selecciona los nombres de los pasajeros Registros de los pasajeros
6. Se muestra el gráfico de asientos para ver todos los asientos disponibles Número de avión, gráfico de asientos,
asientos disponibles
7. El cliente selecciona el (los) asiento(s) para cada pasajero
8. Mostrar página de confirmación y tarjeta de crédito
9. Se verificó la tarjeta de crédito
10. Se envió la confirmación por correo electrónico
11. Se hizo la reservación de la aerolínea
Extensiones o escenarios alternativos
Selección de vuelos
1. Se muestra una lista de vuelos
2. El cliente selecciona un vuelo
3. Se envía la solicitud a la aerolínea
4. El vuelo ya está lleno
Selección de asientos
1. Se muestra una lista de vuelos
2. El cliente selecciona un vuelo
3. Se envía la solicitud a la aerolínea
4. Se obtienen las reservaciones de asientos
5. Se muestra el gráfico de asientos
6. El cliente no puede encontrar un asiento aceptable
Selección de comidas para los vuelos internacionales
1. El cliente selecciona la comida de la lista desplegable Lista de comidas disponibles de la aerolínea
2. Se actualiza el registro con la selección de comida Registro de comida del cliente
FIGURA 2.17
Los casos de uso pueden incluir pasos condicionales
así como extensiones o escenarios alternativos.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 43
El área de Precondiciones, en la sección del pie de página del escenario del caso de uso, muestra una lista
de lo que debe ocurrir antes de que el participante pueda registrarse para una conferencia. En este ejemplo, el
participante debe haber iniciado sesión ya como miembro de la sociedad, además de contar con un ID de usua-
rio y contraseña válidos. El área Postcondiciones muestra una lista de lo que ha logrado el caso de uso. El área
Suposiciones muestra una lista de las premisas básicas que el analista supone han sido cumplidas por el actor de
antemano. El área Requerimientos cumplidos muestra por qué este caso de uso es importante y necesario para
que el área de negocios pueda tener éxito. La prioridad es una indicación de los casos de uso que se deben desa-
rrollar primero y los que se pueden postergar. El riesgo es una evaluación aproximada en relación con la posibili-
dad de que surjan problemas o dificultades al desarrollar el caso de uso. En este caso, el riesgo es medio debido a
que el caso de uso de registro requiere un servidor seguro y acepta información de tarjetas de crédito.
Creación de las descripciones de los casos de uso
Use los siguientes cuatro pasos para crear descripciones de casos de uso:
1. Use historias ágiles, los objetivos de la definición del problema, requerimientos de los usuarios o una lista de
características como punto de inicio.
2. Pregunte sobre las tareas que hay que realizar para lograr la transacción. Pregunte si el caso de uso lee datos
o actualiza alguna tabla.
3. Averigüe si hay acciones iterativas o de ciclos.
4. El caso de uso termina cuando se completa el objetivo del cliente.
Por qué son útiles los diagramas de casos de uso
Sin importar el método que utilice para desarrollar su sistema (métodos SDLC tradicionales, métodos ágiles o
métodos orientados a objetos), usted descubrirá que los casos de uso son muy valiosos. Los diagramas de casos
de uso identifican a todos los actores en el dominio del problema, de forma que un analista de sistemas se puede
concentrar en lo que los humanos desean y necesitan para usar el sistema, extender sus capacidades y disfrutar su
interacción con la tecnología.
Las acciones a completar también se muestran con claridad en el diagrama de caso de uso. Esto no sólo fa-
cilita al analista la tarea de identificar los procesos, sino que también ayuda en la comunicación con los demás
analistas en el equipo y con los ejecutivos de la empresa.
El escenario del caso de uso siempre es algo que vale la pena. Como una gran parte de la información que
los usuarios confieren al analista está en forma de historias, es fácil capturar estas historias en la forma de un
escenario de caso de uso. Este escenario siempre documenta el evento desencadenador para que el analista pueda
en todo momento rastrear los pasos que condujeron hacia otros casos de uso. Como se anotan los pasos realiza-
dos, es posible emplear escenarios de casos de uso para escribir procesos lógicos.
Los diagramas de caso de uso se están haciendo populares debido a su sencillez y carencia de detalles téc-
nicos. Se utilizan para mostrar el alcance de un sistema, junto con las principales características del mismo y los
actores que trabajan con esas características principales. Los usuarios ven el sistema, pueden reaccionar a él y
proveer retroalimentación. También pueden ayudar a determinar si se debe crear o comprar el software.
En la figura 2.18 se muestran las principales razones de escribir casos de uso..
NIVELES DE ADMINISTRACIÓN
La administración en las organizaciones existe en tres amplios niveles horizontales: control operacional, planea-
ción y control administrativo (administración de nivel medio), y administración estratégica, como se muestra en
• Los casos de uso comunican los requerimientos del sistema con efectividad, ya que los
diagramas se mantienen simples.
• Los casos de uso permiten a las personas contar historias.
• Las historias de los casos de uso tienen sentido para las personas sin conocimientos técnicos.
• Los casos de uso no dependen de un lenguaje especial.
• Los casos de uso pueden describir la mayoría de los requerimientos funcionales (como las
interacciones entre los actores y las aplicaciones).
• Los casos de uso pueden describir los requerimientos no funcionales (como el rendimiento
y la capacidad de mantenimiento) a través del uso de estereotipos.
• Los casos de uso ayudan a los analistas a definir los límites.
• Los casos de uso se pueden rastrear para que los analistas puedan identificar los enlaces
entre los casos de uso y otras herramientas de diseño y documentación.
FIGURA 2.18
Las principales razones de escribir
casos de uso son su efectividad
para comunicarse con los usuarios
y su capacidad para capturar las
historias de los usuarios.www.xlibros.com

44 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
la figura 2.19. Cada nivel acarrea sus propias responsabilidades y todo el trabajo para lograr las metas y objetivos
de la organización a su propio modo.
El control operacional forma el nivel inferior de la administración de tres niveles. Los gerentes de opera-
ciones toman decisiones mediante el uso de reglas predeterminadas que tienen resultados predecibles cuando se
implementan en forma correcta.
Ellos toman decisiones que afectan a la implementación en los itinerarios de trabajo, el control de inventa-
rios, los embarques, la recepción y el control de procesos como el de producción. Los gerentes de operaciones
supervisan los detalles operativos de la organización.
La administración de nivel medio forma el segundo nivel (intermedio) del sistema de administración de tres
niveles. Los gerentes de este nivel toman decisiones de planeación y control de corto plazo en relación con la
mejor forma de asignar los recursos para cumplir con los objetivos de la organización.
Sus decisiones van desde pronosticar los requerimientos de recursos a futuro, hasta resolver los problemas
de los empleados que amenazan la productividad. El dominio de la toma de decisiones de los gerentes del nivel
Control operacional
Planeación y
control administrativo
Administración
estratégica
FIGURA 2.19
La administración en las
organizaciones existe en tres
niveles horizontales: control
operacional, planeación y control
administrativo, y administración
estratégica.
O P O R T U N I D A D D E C O N S U L T O R Í A 2 . 2
Donde hay carbón hay una copia
“Todavía no sé qué haremos con las hojas rosas”, admitió Ri-
chard Russel. “Son parte de un formulario cuadruplicado que se
puede separar. Todo lo que sé es que debemos conservarlas para el
archivista, para que las archive cuando tenga tiempo”.
Richard es un ejecutivo de cuenta junior recién contratado para
Carbon, Carbon & Rippy, una casa de bolsa. Usted trata de recorrer
los pasos que él lleva a cabo para hacer “oficial” una compra de
acciones, ya que su jefe le pidió a usted que optimizara el proceso
encargado de almacenar y recuperar la información de compra de
acciones en el sistema computacional.
Después de que usted se va, Richard sigue pensando en los
formularios de color rosa. Le dice a su empleado, Harry Schultz: “En
los dos meses que llevo aquí, nunca he visto a alguien que utilice esas
hojas rosa. Me hacen perder mi tiempo y el tuyo, sin mencionar todo
el espacio requerido para archivarlas. Vamos a tirarlas”.
Richard y Harry se ponen a abrir todos los archivos antiguos
que mantenía el predecesor de Richard y tiran todos los formularios
de color rosa archivados, junto con los que se habían acumulado
pero aún no se habían archivado. Les lleva horas, pero hacen mucho
espacio. “En definitiva valió la pena”, asegura Richard a Harry.
Tres semanas después. Una asistente del jefe de Richard lla-
mada Carol Vaness aparece. Richard está feliz de ver una cara co-
nocida y la saluda: “Hola Carol, ¿qué hay de nuevo?”.
“Lo mismo de siempre”, suspira Carol. “Bueno, creo que no es
lo mismo para ti, ya que eres el nuevo. Pero necesito todos esos
molestos formularios de color rosa”.
Casi entrando en shock, Richard intercambia miradas con
Harry y después murmura: “Estás bromeando, ¿verdad?”
Carol se ve más seria de lo que nunca pensó Richard que fuera
posible, y contesta: “Sin bromas. Sintetizo todos los formularios de
color rosa de todos los corredores de bolsa y después comparo mis
totales con la información computarizada sobre las compras de
acciones. Es parte de nuestra auditoría rutinaria de tres meses para
mantener la precisión de nuestras transacciones. Mi trabajo de-
pende del tuyo. ¿Acaso la señorita McCue no te explicó eso cuando
empezaste?”.
¿Qué concepto de sistemas ignoraron Richard y Harry cuando
tiraron los formularios de color rosa? ¿Cuáles son las posibles ra-
mificaciones para los analistas de sistemas si se ignoran los concep-
tos generales de sistemas?www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 45
medio puede caracterizarse de una manera conveniente como parcialmente operacional y parcialmente estraté-
gico, con fluctuaciones constantes.
La administración estratégica es el tercer nivel del control administrativo de tres niveles. Los gerentes estra-
tégicos ven hacia el futuro, más allá de la organización, y toman decisiones que guiarán a los gerentes del nivel
medio y de operación en los meses y años por venir.
Los gerentes estratégicos trabajan en un entorno de toma de decisiones muy incierto. Mediante declaracio-
nes de los objetivos y la determinación de estrategias y políticas para lograrlos, los gerentes estratégicos definen
la organización como un todo. Ellos tienen la visión más amplia, ya sea que la empresa decida desarrollar nuevas
líneas de productos, deshacerse de empresas conjuntas no rentables, adquirir otras empresas compatibles o in-
cluso permitir su propia adquisición o fusión.
Existen marcados contrastes entre las personas que toman decisiones en varias dimensiones. Por ejemplo,
los gerentes estratégicos tienen varios objetivos de decisión, mientras que los gerentes de operaciones tienen uno
solo. A menudo es difícil que los gerentes de nivel superior identifiquen los problemas, pero esto es fácil para los
gerentes de operación. Los gerentes estratégicos se enfrentan a problemas semiestructurados, mientras que
los gerentes de nivel inferior lidian la mayor parte del tiempo con problemas estructurados.
Las soluciones alternativas para un problema al que se enfrentan los gerentes estratégicos a menudo son difí-
ciles de articular, pero las alternativas con las que trabajan los gerentes de operaciones son por lo general fáciles
de enumerar. La mayoría del tiempo los gerentes estratégicos toman decisiones de una sola vez, mientras que las
decisiones que toman los gerentes de operaciones tienden a ser repetitivas.
Implicaciones para el desarrollo de sistemas de información
Cada uno de los tres niveles administrativos contiene distintas implicaciones para desarrollar sistemas de infor-
mación. Algunos de los requerimientos de información para los gerentes son evidentes, mientras que otros son
confusos y se traslapan entre sí.
Los gerentes de operaciones necesitan información interna de naturaleza repetitiva y bajo nivel. Dependen
mucho de la información que captura el rendimiento actual y son grandes usuarios de los recursos de información
en línea y en tiempo real. La necesidad que tienen los gerentes de operaciones de obtener información anterior
sobre el rendimiento e información periódica es sólo moderada. No pueden hacer mucho uso de la información
externa que permite proyecciones a futuro.
En el siguiente nivel administrativo, los gerentes de nivel medio necesitan información de corto y largo pla-
zos. Debido a la naturaleza de sus trabajos relacionada con la localización y solución de problemas, los gerentes
de este nivel experimentan necesidades extremadamente altas de información en tiempo real. Para realizar su
tarea de control en forma apropiada también necesitan información actual sobre el rendimiento medido contra
estándares establecidos. Los gerentes de nivel medio dependen mucho de la información interna. Al contrario de
los gerentes de operaciones, tienen una gran necesidad de información histórica, así como de información que les
permita predecir los eventos futuros y simular numerosos escenarios posibles.
Los gerentes estratégicos difieren un poco de los gerentes de nivel medio y de operaciones en cuanto a sus
requerimientos de información. Dependen mucho de la información proveniente de fuentes externas que sumi-
nistran noticias sobre las tendencias del mercado y las estrategias de las corporaciones competidoras. Debido
a que la tarea de la gerencia estratégica exige realizar pronósticos sobre el futuro incierto, los gerentes estraté-
gicos tienen una gran necesidad de información de una naturaleza predictiva y de información que les permita
crear muchos escenarios distintos del tipo “que pasaría si”. Los gerentes estratégicos también tienen fuertes ne-
cesidades de información basada en informes periódicos, derivadas de su esfuerzo por adaptarse a la evolución
constante.
CULTURA ORGANIZACIONAL
La cultura organizacional es un área establecida de investigación que ha crecido en forma notable en la última
generación. Así como es apropiado pensar que las organizaciones incluyen muchas tecnologías, es igual de apro-
piado verlas como anfitrionas de varias subculturas competentes.
Aún no se ha llegado a un buen acuerdo en cuanto a qué es exactamente lo que constituye una subcultura or-
ganizacional. Sin embargo, hay consenso en cuanto a que las subculturas competentes pueden estar en conflicto
al tratar de ganar partidarios de lo que consideran que debe ser la organización. Se está realizando una investiga-
ción para determinar los efectos de las organizaciones y los equipos virtuales en cuanto a la creación de subcul-
turas cuando los miembros no comparten un espacio de trabajo físico pero sí comparten tareas.
En vez de considerar la cultura como un todo, es más conveniente pensar acerca de los factores determinan-
tes que se pueden investigar sobre las subculturas, como el simbolismo verbal y no verbal. El simbolismo verbal
incluye el lenguaje compartido que se utiliza para construir, transmitir y preservar los mitos, metáforas, visiones
y humor de las subculturas. El simbolismo no verbal incluye los artefactos, ritos y ceremonias que se comparten;www.xlibros.com

46 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Hay tres amplios fundamentos organizacionales que debemos
considerar en el análisis y diseño de sistemas de información: el
concepto de las organizaciones como sistemas, los diversos ni-
veles de administración y la cultura organizacional en general.
Las organizaciones son sistemas complejos compuestos de
subsistemas interrelacionados e interdependientes. Además, los
sistemas y subsistemas se caracterizan debido a que sus entornos
internos existen en un continuo, desde los más abiertos hasta los
más cerrados. Un sistema abierto permite el paso libre de los re-
cursos (personas, información, materiales) a través de sus lími-
tes; los sistemas cerrados no permiten el flujo libre de entradas o
salidas. Las organizaciones y los equipos también se pueden
organizar en forma virtual, de manera que sus miembros se co-
necten por medios electrónicos sin necesidad de estar en el
mismo espacio de trabajo físico. Los sistemas de planificación
de recursos son sistemas de información organizacional (empre-
sarial) integrados que se desarrollan mediante software persona-
lizado y propietario, para ayudar al flujo de información entre las
áreas funcionales de la organización. Soportan una perspectiva
de sistemas de la organización.
O P O R T U N I D A D D E C O N S U L T O R Í A 2 . 3
El poder de la pirámide
“En realidad lo admiramos”, dice Paul LeGon. Como analista
de sistemas, usted recibió una invitación para ayudar a Pyramid,
Inc., una empresa editorial pequeña e independiente que se especia-
liza en libros de portada rústica que están fuera de la corriente do-
minante en la industria editorial.
Paul continúa: “Manejamos lo que algunos consideran temas
marginales. Usted sabe, el poder de la pirámide, las profecías del fin
del mundo y cómo vivir en forma más saludable si pensamos en el
color rosa. Algunas veces cuando las personas ven nuestros libros,
sólo sacuden su cabeza y dicen: ‘Hmm... un tema poco común’.
Pero no somos esclavos de ninguna filosofía en especial, y hemos
tenido mucho éxito. Tanto así que como tengo 24 años, la gente me
llama el ‘niño rey’”. Paul se detiene para descifrar su reacción.
Paul continúa: “Estoy en la cima como presidente y las áreas
funcionales como editorial, contabilidad, producción y marketing
están bajo mi cargo”.
Ceil Toom, asistente de Paul, quien ha estado escuchando en
silencio hasta ahora, irrumpe con sus comentarios: “Los últimos
expertos en sistemas que hicieron un proyecto para nosotros reco-
mendaron la creación de comités de enlace para los empleados entre
los departamentos de contabilidad, producción y marketing, de
manera que pudiéramos compartir el inventario recién computari-
zado y las cifras de ventas entre toda la organización. Ellos argu-
mentaban que los comités de este tipo podrían reducir la duplicación
innecesaria de los resultados, y que cada área funcional se integraría
de una mejor manera con el resto de la empresa”.
Paul entra en la historia y dice: “Estuvo bien —por lo menos
durante un tiempo y los empleados compartieron información, pero la
razón por la que usted está aquí es que los empleados decían que no
tenían tiempo para las reuniones de los comités y no se sentían cómo-
dos al compartir información con las personas de otros departamen-
tos que estaban más arriba de lo que ellos estaban aquí en Pyramid”.
De acuerdo con Paul y Ceil, ¿cuáles fueron los efectos de
instalar un sistema de información administrativa en Pyramid, Inc.
en el que las personas tenían que compartir información en formas
que no eran consistentes con su estructura? Proponga algunas for-
mas generales de resolver este problema, de manera que los emplea-
dos de Pyramid puedan obtener las cifras de ventas e inventario que
necesitan.
la ropa de los que toman decisiones y los trabajadores; el uso, la ubicación y decoración de las oficinas; y los ritua-
les para celebrar los cumpleaños, promociones y retiros de los miembros.
Las subculturas coexisten dentro de las culturas organizacionales “oficiales”. La cultura con sanciones ofi-
ciales puede prescribir un código de vestimenta, formas adecuadas de dirigirse a los superiores y a los compañe-
ros trabajadores, y formas apropiadas de lidiar con el público. Las subculturas pueden ser factores determinantes
poderosos de los requerimientos de información, disponibilidad y uso.
Los miembros de la organización pueden pertenecer a una o más subculturas dentro de la organización. Las
subculturas pueden ejercer una poderosa influencia en el comportamiento de sus miembros, incluyendo las
sanciones a favor o en contra del uso de los sistemas de información.
La acción de comprender y reconocer las subculturas organizacionales predominantes puede ayudar a los
analistas de sistemas a vencer la resistencia al cambio que surge al momento de instalar un nuevo sistema de in-
formación. Por ejemplo, el analista podría idear cierto tipo de capacitación para lidiar con cuestiones específicas
de las subculturas organizacionales. También puede ser útil identificar las subculturas para el diseño de los siste-
mas de soporte de decisiones que se ajustan a la interacción con grupos de usuarios específicos.
RESUMENwww.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 47
E X P E R I E N C I A D E H Y P E R C A S E ® 2
Las culturas y subculturas organizacionales son factores deter-
minantes importantes de la forma en que las personas utilizan la
información y los sistemas de información. Al posicionar los siste-
mas de información en el contexto de las organizaciones como un
sistema más grande, es posible comprender que muchos factores
son importantes y hay que tenerlos en consideración al establecer
los requerimientos de información, y al diseñar e implementar los
sistemas de información.
Preguntas de HYPERCASE
1. ¿Qué cambio organizacional importante se llevó a cabo
recientemente en MRE? ¿Qué departamento o departamentos
estuvieron involucrados? ¿Por qué se efectuó el cambio?
2. ¿Cuáles son los objetivos del Departamento de sistemas de
capacitación y administración?
3. ¿Clasificaría a MRE como una industria de servicios, fabricante
o ambos? ¿Qué tipo de “productos” son los que MRE
“produce”? Sugiera cómo el tipo de industria en la que se
encuentra MRE afecta a los sistemas de información que utiliza.
4. ¿Qué tipo de estructura organizacional tiene MRE? ¿Cuáles
son las implicaciones de esta estructura para MIS?
5. Describa en un párrafo la “política” del Departamento de
sistemas de capacitación y mantenimiento en MRE. ¿Quiénes
están involucrados y cuáles son algunas de las cuestiones
principales?
6. Dibuje un diagrama de caso de uso que represente las
actividades del grupo Webster Design en MRE en cuanto al
desarrollo de los planes maestros del sitio y las instalaciones
(use el sitio Web de MRE para obtener su información básica).
FIGURA 2.HC1
Haga clic en las palabras clave de HyperCase
para obtener más detalles
“Parece que ha empezado bien en MRE. Me
agrada saber que conoció a Snowden Evans.
Como sabe, se reportará directamente con él du-
rante su proyecto de consultoría. Como su asis-
tente administrativa durante los últimos cinco
años, le puedo decir mucho sobre la empresa,
pero recuerde que hay varias formas de obtener
más información. Le recomiendo entrevistar a
los usuarios, observar sus entornos de toma de
decisiones y analizar los informes, gráficos y
diagramas en el archivo. Para ello puede hacer
clic en el directorio telefónico y obtener una cita
con quien desee entrevistar; o bien en el mapa del
edificio para ver su distribución, o en el sitio Web
corporativo para ver las áreas funcionales y las
relaciones jerárquicas formales en MRE”.
“Muchas de las reglas de la vida corporativa
se aplican en el caso de MRE en HyperCase.
Puede caminar libremente en muchas áreas pú-
blicas. Pero si desea dar un paseo por una oficina
privada, primero debe reservar una cita con uno
de nuestros empleados. Algunas áreas seguras
quedan estrictamente prohibidas para usted como
externo, ya que podría provocar un riesgo de seguridad”.
“De todas formas, no creo que nos considere excesivamente re-
servados, ya que puede suponer que cualquier empleado que le conceda
una entrevista también le concederá el acceso al material de archivo en
su posesión, así como al trabajo actual en sus escritorios o pantallas”.
“Por desgracia, algunas personas en la empresa parecen nunca
estar disponibles para los consultores. Le sugiero que sea persis-
tente. Hay muchas formas de obtener información sobre las perso-
nas y los sistemas de MRE. La creatividad tiene su recompensa.
Con el tiempo descubrirá que los consultores de sistemas que siguen
sus corazonadas agilizan sus habilidades técnicas y nunca dejan de
pensar en resolver todos los acertijos en MRE, son los que obtienen
los mejores resultados”.
“Recuerde utilizar varios métodos (entrevistas, observación e
investigación) para comprender lo que en MRE tratamos de decirle.
¡Algunas veces las acciones, los documentos y las oficinas hablan
con más fuerza que las palabras!”
Hay muchas formas de describir gráficamente el sistema. El
analista debe elegir una de estas herramientas lo más pronto posible
para obtener una visión general del sistema. Estas metodologías
incluyen dibujar diagramas de flujo de datos a nivel de contexto,
capturar las relaciones lo antes posible mediante diagramas de enti-
dad-relación; dibujar diagramas de casos de uso o escribir escena-
rios de casos de uso con base en las historias de los usuarios. Puede
ser útil para el analista utilizar estos diagramas y técnicas al princi-
pio del análisis para definir los límites y el alcance del sistema,
además de que le será más fácil centrar la atención en las personas
y sistemas que son externas al sistema que se va a desarrollar.
Los diagramas de entidad-relación ayudan al analista de sistemas
a comprender las entidades y relaciones que conforman el sistema or-
ganizacional. Los diagramas E-R pueden describir las relaciones de
uno a uno, de uno a varios, de varios a uno y de varios a varios.
Los tres niveles de control administrativo son control operacio-
nal, administración de nivel medio y control estratégico. El horizonte
temporal de la toma de decisiones es distinto para cada nivel.www.xlibros.com

48 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
PALABRAS CLAVE Y FRASES
actor
administración de nivel medio
administración de operaciones
administración estratégica
alcance del sistema
apertura
capacidad de interrelacionarse
caso de uso
cerrazón
cuatro niveles de casos de uso
cultura organizacional
diagrama de caso de uso
diagrama de flujo de datos a nivel de contexto
diagramas de entidad-relación (E-R)
empresa virtual
entidad (entidad fundamental)
entidad asociativa
entidad atributiva
entorno
equipo virtual
escenario de caso de uso
interdependiente
límites organizacionales
notación tipo pata de cuervo
organización virtual
planificación de recursos empresariales (ERP)
retroalimentación
sistemas
sistemas empresariales
PREGUNTAS DE REPASO
1. ¿Cuáles son los tres grupos de fundamentos organizacionales que conllevan implicaciones para el desarrollo de los
sistemas de información?
2. ¿Qué significa decir que los subsistemas organizacionales están interrelacionados y son interdependientes?
3. Defina el término límite organizacional.
4. ¿Cuáles son los dos principales propósitos de la retroalimentación en las organizaciones?
5. Defina la apertura en un entorno organizacional.
6. Defina la cerrazón en un entorno organizacional.
7. ¿Cuál es la diferencia entre una organización tradicional y una virtual?
8. ¿Cuáles son los potenciales beneficios y una desventaja de una organización virtual?
9. Dé un ejemplo de la forma en que los analistas de sistemas podrían trabajar con los usuarios como un equipo virtual.
10. ¿Qué son los sistemas empresariales?
11. ¿Qué es ERP y cuál es su propósito?
12. ¿A qué problemas se enfrentan con frecuencia los analistas cuando tratan de implementar un paquete ERP?
13. ¿Cuáles son los dos símbolos en un diagrama de caso de uso y qué representan?
14. ¿Qué es un escenario de caso de uso?
15. ¿Cuáles son las tres partes principales de un escenario de caso de uso?
16. ¿Cuáles son los cuatro pasos para elaborar descripciones de casos de uso?
17. ¿Cuáles son las cinco metáforas de altitud para describir un caso de uso en distintos niveles? ¿Qué representan?
18. ¿Qué representa un proceso en un diagrama de flujo de datos a nivel de contexto?
19. ¿Qué es una entidad en un diagrama de flujo de datos?
20. ¿Qué significa el término diagrama de entidad-relación?
21. ¿Qué símbolos se utilizan para dibujar diagramas E-R?
22. Enliste los tipos de diagramas E-R.
23. ¿Cuál es la diferencia entre una entidad, una entidad asociativa y una entidad atributiva?
24. Liste los tres niveles amplios horizontales de administración en las organizaciones.
25. ¿Cómo puede ayudar la comprensión de las subculturas organizacionales en el diseño de los sistemas de información?
PROBLEMAS
1. “Es difícil determinar qué queremos. Veo lo que están haciendo nuestros competidores, las tiendas de conveniencia, y
pienso que deberíamos copiarlos. Después entran cien clientes y escucho a cada uno de ellos decir que debemos seguir
igual, con nuestra pequeña tienda, empleados amigables y cajas registradoras antiguas. Luego, cuando leo un ejemplar
del Supermarket News, dicen que la ola del futuro son las supertiendas de abarrotes, sin precios individuales etiquetados
y donde los escáneres de UPC sustituyen a los empleados. Me inclino hacia tantas direcciones que no puedo definir
realmente una estrategia para nuestra tienda de abarrotes”, admite Geoff Walsham, propietario y gerente de Jiffy Geoff’s
Grocery Store.
Aplique en un párrafo el concepto de límites organizacionales permeables para analizar el problema de Geoff en
cuanto a enfocarse en los objetivos organizacionales.
2. Escriba siete enunciados que expliquen las relaciones de derecha a izquierda en la figura 2.8.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 49
3. Dibuje un diagrama de entidad-relación de una relación entre paciente-doctor.
a. ¿Qué tipo de diagrama E-R es?
b. Explique en uno o dos enunciados por qué se elabora el diagrama de la relación paciente-doctor de esta forma.
4. Usted empezó a dibujar diagramas E-R tan pronto como entró a la organización al cuidado de la salud para la cual va a
desarrollar un sistema. El miembro de su equipo es algo escéptico en cuanto al uso de diagramas E-R antes de empezar
con el diseño de la base de datos. En un párrafo convenza al miembro de su equipo de que vale la pena usar lo más
pronto posible los diagramas E-R.
5. Neil es el encargado de tomar las decisiones en la empresa Pepe’s Atlantic Sausage Company. Como hay varios
proveedores de ingredientes y sus precios fluctúan, ha ideado varias formulaciones distintas para las diversas
salchichas que fabrica, de acuerdo con la disponibilidad de ciertos ingredientes de proveedores específicos. Después
ordena los ingredientes correspondientes dos veces por semana. Aunque no puede predecir cuándo estarán disponibles
los ingredientes a un precio específico, la forma en que realiza los pedidos de provisiones se puede considerar
rutinaria.
a. ¿En qué nivel de administración está trabajando Neil? Explíquelo en un párrafo.
b. ¿Qué atributos de su trabajo tendría que cambiar antes de poder clasificarlo en un nivel de administración distinto?
Haga una lista de estos atributos.
6. Muchas de las personas que trabajan en Pepe’s (problema 5) son extremadamente dedicadas, por lo cual han trabajado
toda su vida en la empresa. Otros sienten que la empresa está atrasada y debería utilizar sistemas de producción y
sistemas de información más avanzados, además de optimizar la administración de la cadena de suministro para que la
empresa sea más competitiva. Los miembros de un tercer grupo sienten que nadie aprecia lo que hacen. Describa con
palabras las diversas subculturas. Asígneles un nombre con base en sus emociones.
7. Alice, del departamento de recursos humanos de la planta Cho Manufacturing recibe constantes preguntas de sus
empleados en relación con la cantidad que se deduce de su sueldo para cubrir seguro, impuestos, gastos médicos, retiro
obligatorio y retiro voluntario. “Me quitan unas cuantas horas al día”, dice Alice.
A ella le gustaría un sistema Web que permitiera a los usuarios iniciar sesión en forma segura para ver la información.
Alice desea que el sistema se comunique con las empresas de seguros médicos y dentales para obtener la cantidad
restante en la cuenta del empleado durante el año. También le gustaría obtener los montos de retiro ahorrados, así como
los resultados de las inversiones. Alice se preocupa mucho por la privacidad y desea que el sistema haga que los
empleados se registren y otorguen su permiso para obtener los montos financieros de las empresas de seguros médicos y
dentales, así como de las empresas de retiro. Dibuje un diagrama de caso de uso que represente las actividades del
sistema Prestaciones de los empleados.
8. Escriba un escenario para el diagrama de caso de uso que construyó para la empresa Cho Manufacturing.
9. ¿En qué nivel va a crear su caso de uso? Seleccione una de las cuatro metáforas de altitud y explique por qué la
eligió.
10. Cree un diagrama de flujo de datos a nivel de contexto para el sistema Prestaciones de los empleados, del problema 7.
Aventure algunas suposiciones sobre los datos que entran y salen del proceso central. ¿Le parece que esto es mejor o
peor para explicar a Alice el funcionamiento del sistema, en vez de usar el caso de uso y los escenarios de caso de uso?
11. Dibuje un caso de uso y escriba un escenario de caso de uso para obtener dos o tres cuentas de correo electrónico. Piense
en los pasos necesarios para asegurar la seguridad.
PROYECTOS EN GRUPO
1. Haga grupos de cinco personas. Asigne una persona para que actúe como el diseñador del sitio Web, una para que
escriba la copia del producto de una empresa, otra para que lleve el registro de los pagos de los clientes, una más para
que supervise la distribución y otra para atender a los clientes que tengan preguntas sobre el uso del producto. Después
seleccione un producto simple (que no tenga muchas versiones). Algunos ejemplos adecuados son una cámara digital, un
reproductor de DVD, un GPS una caja de dulces o una gorra de viaje especializada (a prueba de lluvia o para bloquear el
sol). Ahora invierta 20 minutos en tratar de explicar al diseñador del sitio Web qué debe incluir en éste. Describa en unos
tres párrafos la experiencia que tuvo su grupo en cuanto a la coordinación. Proporcione más información sobre la
capacidad de interrelación de los subsistemas en la organización (su grupo).
2. En un pequeño grupo, desarrolle un caso de uso y un escenario de caso de uso para hacer reservaciones aéreas, de hotel
y de automóvil para viajar a nivel nacional.
3. Cambie su respuesta en el Proyecto en grupo 2 para incluir viajes internacionales. ¿Cómo cambian el caso de uso y el
escenario de caso de uso?
4. Dibuje con su grupo un diagrama de flujo de datos a nivel de contexto del sistema de registro de su escuela o
universidad. Identifique cada una de las entidades y los procesos. Discuta con sus compañeros por qué parece haber
distintas formas de dibujar el diagrama; llegue a un consenso con ellos en cuanto a la mejor forma de dibujar el
diagrama y defienda su elección en un párrafo. Ahora trabaje con los miembros de su grupo y siga los pasos
apropiados para desarrollar un diagrama E-R y cree uno para el sistema de registro de su escuela o universidad.
Asegúrese de que su grupo indique si la relación que describe es de uno a uno, de uno a varios, de varios a uno o de
varios a varios.www.xlibros.com

50 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
BIBLIOGRAFÍA SELECCIONADA
Bleeker, S.E. “The Virtual Organization”. Futurist, Vol. 28, Núm. 2, 1994, pp. 9-14.
Chen, P. “The Entity-Relationship Model—Towards a Unified View of Data”. ACM Transactions on Database Systems, Vol. 1,
marzo de 1976, pp. 9-36.
Ching, C., C. W. Holsapple y A. B. Whinston. “Toward IT Support for Coordination in Network Organizations”. Information
Management, Vol. 30, Núm. 4, 1996, pp. 179-199.
Cockburn, A. “Use Case Icons”, http://alistair.cockburn.us/Use+case+icons?version=8339&diff=8339&with=6296. Último
acceso en marzo 18, 2009.
Davis, G.B. y M. H. Olson. Management Information Systems: Conceptual Foundation, Structure, and Development, 2da. ed.
Nueva York: McGraw-Hill, 1985.
Galbraith, J. R. Organizational Design, Reading, MA: Addison-Wesley, 1977.
Kendall, K. E., J. R. Buffington y J.E. Kendall. “The Relationship of Organizational Subcultures to DSS User Satisfaction”.
Human Systems Management, marzo 1987, pp. 31-39.
Kulak, D. y E. Guiney. Use Cases: Requirement in Context, 2da. ed. Boston: Pearson Education, 2004.
PeopleSoft. Disponible en: www.peoplesoft.com/corplen/public_index.jsp. Acceso en junio 3, 2003.
Warkentin, M., L. Sayeed y R. Hightower. “Virtual Teams versus Face-to-Face Teams: An Exploratory Study of a Web-Based
Conference System”. En Emerging Information Technologies: Improving Decisions, Cooperation, and Infrastructure.
Editado por K. E. Kendall, pp. 241-262. Thousand Oaks, CA: Sage Publications, 1999.
Yager, S.E. “Everything’s Coming Up Virtual”. Disponible en: www.acm.org/crossroads/xrds4-1/organ.html. Acceso en junio
3, 2003.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 51
E P I S O D I O 2
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Descripción gráfica de las relaciones
“Entonces el proyecto implica algo más que sólo realizar trabajo de mantenimiento en los programas actuales”, dice Chip.
“¿Vamos a usar una metodología formal para analizar y diseñar el nuevo sistema?”
“Sí”, responde Anna. “También vamos a usar Microsoft Visio para crear y modificar los diagramas, así como cierta infor-
mación simple del repositorio. También tenemos una herramienta CASE, Visible Analyst, para analizar y diseñar el sistema. 1
Hace poco instalamos los productos en la computadora de la oficina”.
Con unos cuantos clics del ratón, Anna produce un diagrama de flujo de datos a nivel de contexto (vea la figura E2.1).
“Es muy conveniente empezar a pensar en el sistema de esta manera”, dice Anna al momento en que ven el diagrama en la
pantalla.
Chip asiente y dice: “Puedo ver con mucha facilidad lo que crees que está ocurriendo con el sistema. Por ejemplo, veo que
la entidad externa Administración suministra las preguntas sobre hardware y software y recibe a cambio las respuestas corres-
pondientes. Muestra al sistema dentro de la organización de mayor tamaño”.
“También dibujé un diagrama E-R preliminar del sistema”, dice Anna al momento de mostrar el diagrama de entidad-re-
lación en la pantalla (vea la figura E2.2). “Tal vez haya que modificarlo a medida que aprendamos más sobre el sistema”.
“Sí, las relaciones de varios a varios y de uno a varios son muy claras cuando lo vemos de esta forma”, dice Chip, viendo
a la pantalla.
“Hay una vista más del sistema”, continúa Anna al momento en que abre el diagrama de caso de uso. “Éste es el diagrama
de caso de uso preliminar para nuestro sistema (vea la figura E2.3). Vamos a utilizarlo para obtener retroalimentación de los
usuarios que nos puede ser de utilidad. Los casos de uso no están completos, pero les puedo mostrar uno de ellos”. Anna hace
Formulario para nueva computadora
Se recibió software
Se reparó computadora
Informe maestro de hardware
Informe maestro de software
EE 4
Contexto
Respuesta a pregunta de hardware
Respuesta a pregunta de software
Pregunta de hardware
Pregunta de software
Pregunta de software Respuesta a pregunta
EE 1
Administración
EE 2
Cuerpo
docente
Sistema de
inventario de
computadoras
Soporte
de oficina
EE 5
EE 3
Mantenimiento
EE 1
Administración
EE 2
Cuerpo
docente
Depto. de
embarques/
recepción
FIGURA E2.1
Diagrama de flujo de datos a nivel
de contexto del sistema actual.
1Para obtener más detalles sobre cómo empezar a usar Visible Analyst, vea la obra de Allen Schmidt, Working with
Visible Analyst, 2da. edición (Upper Saddle River, NJ: Prentice Hall, 2004).www.xlibros.com

52 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
tiene
Software
se realiza en Computadora puede tener Hardware
y software
se encuentra
dentro de
tiene provee garantía
Distribuidor
Cuarto
Sistema operativo
Mantenimiento
de computadora
FIGURA E2.2
Diagrama de entidad-relación del
sistema actual.
Departamento de
embarques/recepción
Usuario del software
Crear categoría
de software
<<extiende>>
Mantenimiento
Soporte de oficina
Administración
Agregar
nueva computadora
Agregar software
Producir informe de
inversión de hardware
Producir informe de
referencia cruzada
de hardware y software
Consultar clases
de capacitación
FIGURA E2.3
Diagrama de caso de uso para el
sistema de cómputo de la CPU.www.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 53
clic en el símbolo del caso de uso para mostrar la descripción del caso de uso en el repositorio que aparece
en la figura E2.4.
“Ya tienes un buen comienzo aquí”, continúa Chip a medida que echa un vistazo a la descripción del
caso de uso. “Esto nos ayuda a comprender las actividades que se realizan. Vamos a trabajar y ver qué hay
que hacer ahora”.
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver e imprimir el diagrama de flujo de datos a nivel de
contexto para el sistema de inventario de computadoras, como lo hicieron Chip y Anna.
E-2. Use la característica Repository (Repositorio) o la página Web Repository (Repositorio Web) para ver
la entrada para el proceso central.
E-3. Use Microsoft Visio o Visible Analyst para ver e imprimir el diagrama de entidad-relación para el
sistema de inventario de computadoras.
E-4. Explique por qué las entidades externas en el diagrama a nivel de contexto no se encuentran en el
diagrama de entidad-relación.
Nombre del caso de uso: Agregar computadora
Área: Inventario de computadoras
Actores: Departamento de embarque/recepción, Mantenimiento
Interesados: Cuerpo docente, estudiante, personal
Nivel: Azul
Descripción: Agregar una nueva computadora y generar una lista de todas las máquinas para instalación de software
Evento desencadenador: Se hizo clic en la opción del menú Add Computer (Agregar computadora)
Tipo de desencadenador: Externo Temporal
Pasos realizados (ruta principal)
1. Se introduce la información sobre las nuevas computadoras.
2. Se agrega la computadora al Archivo maestro de computadoras.
3. Se actualizan los pedidos pendientes con las computadoras que
se recibieron.
4. Se produce el informe de Listado de instalaciones para todos
los modelos de escritorio.
5.
Se produce un informe de Listado de instalación de software en el
que se muestra todo el software estándar para todas las
computadoras que se recibieron.
Información para los pasos
Factura y hojas de especificaciones
Archivo maestro de computadoras
Tabla de la base de datos Pending Order
(Pedidos pendientes).
Archivo maestro de computadoras
Archivo maestro de computadoras
Precondiciones: El departamento de recepción recibió una computadora.
Postcondiciones: Se agregó una computadora a la base de datos y se generaron informes.
Suposiciones: El usuario inició sesión exitosamente con acceso a la pantalla Add Computer (Agregar computadora).
Garantía de éxito: Que se haya agregado una computadora a la base de datos y se hayan impreso los informes requeridos.
Garantía mínima: Que se haya recibido la computadora y se agregue más tarde.
Requerimientos cumplidos: Agregar e instalar nuevas computadoras.
Cuestiones pendientes: Curso de acción a seguir cuando las computadoras pendientes no coinciden con las que se recibieron.
Prioridad (opcional): Alta
Riesgo (opcional): Medio
FIGURA E2.4
Escenario de caso de uso para el
sistema computacional de la CPU.www.xlibros.com

54 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
E-5. Explique por qué las entidades ADMINISTRACIÓN y CUERPO DOCENTE se encuentran en ambos lados del proceso
en el diagrama a nivel de contexto.
E-6. Use Microsoft Visio o Visible Analyst para ver e imprimir el diagrama de caso de uso para el sistema de inventario de
computadoras.
E-7. Agregue los siguientes actores y casos de uso al diagrama de casos de uso:
a. El actor CUERPO DOCENTE al lado izquierdo del diagrama de casos de uso.
b. Conectar el actor CUERPO DOCENTE con el caso de uso CONSULTAR CLASES DE CAPACITACIÓN.
c. Como las computadoras pueden tener software instalado para un laboratorio computacional específico, el personal
de soporte de oficina puede hacerse cargo de instalar software en las. Conecte el actor SOPORTE DE OFICINA al
caso de uso AGREGAR SOFTWARE.
d. Agregue dos nuevos casos de uso debajo del caso de uso CONSULTAR CLASES DE CAPACITACIÓN: CONSUL-
TAR EXPERTO DE SOFTWARE y debajo de éste, CONSULTAR INFORMACIÓN DE SOFTWARE.
e. Conecte el actor CUERPO DOCENTE a los casos de uso CONSULTAR EXPERTO DE SOFTWARE y CONSUL-
TAR INFORMACIÓN DE SOFTWARE.
f. Conecte el actor ADMINISTRACIÓN al caso de uso CONSULTAR EXPERTO DE SOFTWARE.
E-8. Agregue el caso de uso INSTALAR COMPUTADORA DE ESCRITORIO al área superior derecha del diagrama. Este
caso de uso extiende al caso de uso AGREGAR COMPUTADORA.
E-9. Agregue una descripción para el caso de uso AGREGAR SOFTWARE. Esta descripción debe contener la siguiente in-
formación:
a. Obtenga el nombre del caso de uso y los actores del diagrama de casos de uso. Los interesados y el nivel son los
mismos que en la figura E2.3.
b. La descripción debe ser: Agregar nuevo software a la tabla Software de la base de datos e imprimir un listado de
instalación.
c. La actividad empieza (se desencadena) cuando el usuario hace clic en el elemento de menú Add Software (Agregar
software).
d. Los pasos realizados y la información para los pasos son:
e. Las precondiciones son el software que se recibió. Las postcondiciones son que el software se agregó a la base de
datos y se crearon los informes. Las suposiciones son que el usuario inició sesión con éxito y tiene acceso a la pan-
talla Add Software (Agregar software). Una garantía de éxito es que se haya agregado el software a la base de datos
y se haya impreso el informe requerido. Una garantía mínima es que se haya recibido el software. Los objetivos
cumplidos son agregar e instalar nuevo software. La cuestión pendiente es cómo determinar qué software instalar en
cuáles equipos. La prioridad es alta y el riesgo es medio.
E-10. Escriba la descripción para el caso de uso PRODUCIR INFORME DE REFERENCIA CRUZADA DE HARDWARE Y
SOFTWARE. Use el diagrama de casos de uso para determinar la información del encabezado y haga todas las suposi-
ciones razonables. Los pasos serían leer un registro de software, usar esa información para leer la tabla relacional de
hardware-software y después leer el registro de hardware. Use el registro de hardware para imprimir una línea en la que
se acumulen los totales. Imprima subtotales y totales generales. Ésta es una actividad de nivel medio y bajo riesgo. Las
precondiciones son que la información se debe haber agregado antes a las tablas de base de datos apropiadas. Las postcon-
diciones son que se imprimió el informe. Las suposiciones son que toda la información en las tablas de base de datos es
correcta. Una garantía de éxito sería que se haya creado el informe con éxito. Una garantía mínima sería que no se haya
podido imprimir el informe. Los objetivos cumplidos son producir información sobre el software instalado en cada má-
quina. Las cuestiones pendientes son: ¿Qué pasa si el software es antiguo y no está instalado actualmente en ninguna
máquina? ¿Cómo se debe producir el informe: impreso, en un archivo PDF o habría que consultar qué paquete de soft-
ware se debe utilizar?
El software se introduce en el nuevo sistema y se valida Formulario de software recibido
El software se agrega al Archivo maestro de software Archivo maestro de software
Se produce la Lista de instalación de software Archivo maestro de software, Pedido
Se notifica al usuario de software sobre el software instalado Pedidowww.xlibros.com

CAPÍTULO 2 • COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES 55
E-11. Escriba la descripción para el caso de uso PRODUCIR INFORME DE INVERSIÓN DE HARDWARE. Use el diagrama
de casos de uso para definir la información del encabezado. Los pasos implican leer cada registro de hardware, contar el
número de equipos y calcular el monto total invertido en ellos para cada modelo de computadora. Calcular subtotales
para cada marca de computadora y un gran total al final del informe. Toda la información proviene de la tabla de base de
datos Hardware Master (Archivo maestro de hardware). Haga todas las suposiciones razonables en cuanto a las precon-
diciones, postcondiciones, suposiciones, garantía de éxito, garantía mínima, objetivos cumplidos, cuestiones pendientes,
prioridad y riesgo.
E-12. Escriba la descripción para el caso de uso CONSULTAR CLASES DE CAPACITACIÓN. Use el diagrama de casos de
uso para definir la información del encabezado. Los pasos implican introducir información en el formulario Web, validar
la información y almacenar los datos en una tabla de base de datos llamada Training Request (Solicitud de capacitación).
Haga todas las suposiciones razonables en cuanto a las precondiciones (por ejemplo, si el software tiene que estar com-
prado de antemano), postcondiciones, suposiciones, garantía de éxito, garantía mínima, objetivos cumplidos, cuestiones
pendientes, prioridad (ésta sería una tarea de alta prioridad) y riesgo.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios. O también pueden resolver muchos de los ejercicios a mano si no tienen el software a su dis-
posición.www.xlibros.com

56 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
56
C A P Í T U L O 3
Administración de proyectos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender cómo se inician y seleccionan los proyectos, definir un problema de
negocios y determinar la viabilidad de un proyecto propuesto.
2. Hacer un inventario y valorar los componentes actuales y propuestos de hardware y
software, y determinar la forma en que brindan soporte a las interacciones de los
humanos con la tecnología.
3. Evaluar las soluciones considerando ventajas y desventajas de crear software personalizado,
comprar software COTS y subcontratar un proveedor de servicios de aplicaciones.
4. Pronosticar y analizar los costos y beneficios tangibles e intangibles.
5. Planear un proyecto al identificar las actividades y programarlas.
6. Administrar los miembros del equipo y las actividades de análisis y diseño, de manera
que se cumplan los objetivos del proyecto sin exceder el tiempo programado.
7. Escribir y presentar en forma profesional una propuesta de sistemas efectiva, con
énfasis tanto en el contenido como en el diseño.
Iniciar proyectos, determinar su viabilidad, programar fechas y tiempos
para su cumplimiento, planificar y después administrar las actividades y a
los miembros del equipo para optimizar la productividad son aptitudes que
el analista de sistemas debe dominar. Como tales, se consideran los funda-
mentos de administración de los proyectos.
Un proyecto de sistemas empieza con problemas o con oportunidades
de realizar mejoras en una empresa que, con frecuencia, surgen a medida que la organización
se adapta al cambio. La creciente popularidad del comercio electrónico evidencia cambios
fundamentales a medida que las empresas originan sus negocios en —o transfieren sus ope-
raciones internas y sus relaciones externas a— Internet. Los cambios que requieren una solu-
ción de sistemas ocurren tanto en el entorno legal como en el industrial. Los analistas trabajan
con los usuarios para crear la definición de un problema que refleje los sistemas y problemas
actuales de la empresa. Una vez que se sugiere un proyecto, el analista de sistemas trabaja
rápidamente con los encargados de tomar las decisiones para determinar si es viable. Si se
aprueba un proyecto para realizar un estudio completo de sistemas, las actividades del pro-
yecto se programan por medio de herramientas tales como los gráficos de Gantt y los diagra-
mas de Técnicas de evaluación y revisión de programas (PERT) para completar el proyecto a
tiempo. Parte del proceso de asegurar la productividad de los miembros del equipo de análisis
de sistemas es administrar de manera efectiva sus actividades programadas. Este capítulo está
dedicado a analizar los fundamentos de la administración de proyectos.
INICIACIÓN DEL PROYECTO
Los proyectos de sistemas tienen muchos orígenes y diversas razones. Algunos de los proyectos
sugeridos sobrevivirán varias de las etapas de evaluación en las que usted (o usted y su equipo)
debe trabajar; otros no deben sobrevivir (ni sobrevivirán) tanto. Los empresarios sugieren pro-www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 57
yectos de sistemas por dos amplios tipos de razones: 1) porque experimentan problemas que se prestan por sí
solos a las soluciones de sistemas y 2) porque reconocen oportunidades para mejorar mediante la actualización o
modificación de los sistemas existentes, o la instalación de sistemas nuevos. Ambas situaciones pueden surgir a
medida que la organización se adapta y hace frente a los cambios naturales y evolucionarios.
Problemas en la organización
A los gerentes no les gusta que su organización tenga problemas y mucho menos hablar sobre ellos o compar-
tirlos con alguien externo. Sin embargo, los buenos gerentes están conscientes de que es imprescindible reconocer
los síntomas de los problemas o, en una etapa posterior, diagnosticar los problemas en sí y luego confrontarlos, si
quieren que su empresa siga funcionando con el mayor potencial posible.
Los problemas salen a la superficie de muchas formas. Una manera de conceptualizar qué son los problemas
y cómo surgen es considerarlos como situaciones en las que nunca se cumplieron los objetivos o dejaron de cum-
plirse en algún punto. La retroalimentación práctica proporciona información sobre el hueco entre el rendimiento
actual y el esperado, y, de esta forma, ayuda a destacar los problemas.
En algunos casos, los problemas que requieren de los servicios de los analistas de sistemas se descubren
debido a que no se están cumpliendo las medidas de rendimiento. Los problemas (o síntomas de ellos) con pro-
cesos que no son visibles en el proceso de salida y que podrían requerir la ayuda de un analista de sistemas; in-
cluyen errores excesivos y un trabajo que se desempeña con mucha lentitud, en forma incompleta, incorrecta o
que simplemente no se lleva a cabo. Otros síntomas de los problemas se hacen evidentes cuando las personas no
cumplen con los objetivos de rendimiento de referencia. Los cambios en el comportamiento de los empleados,
como niveles altos e inusuales de ausentismo, una gran inconformidad en el trabajo o mucha rotación de personal
son factores que alertan a los gerentes sobre problemas potenciales. Cualquiera de estos cambios, por sí solos o
combinados, podría ser motivo suficiente para solicitar la ayuda de un analista de sistemas.
Aunque las dificultades como las que acabamos de describir ocurren en la organización, la retroalimenta-
ción acerca de la forma en que la organización cumple con los objetivos designados puede provenir del exterior,
en forma de quejas o sugerencias de los clientes, distribuidores o proveedores, además de la pérdida de ventas o
una reducción inesperada en las mismas. Esta retroalimentación proveniente del entorno externo es en extremo
importante y no debe ignorarse.
En la figura 3.1 se muestra un resumen de síntomas de problemas y metodologías útiles para detectarlos.
Note que revisar la salida, observar o investigar el comportamiento de los empleados y escuchar la retroalimen-
tación de las fuentes externas son valiosas herramientas para detectar problemas. Al reaccionar a las historias de
los problemas en la organización, el analista de sistemas desempeña los roles de consultor, experto de soporte y
agente de cambio, como vimos en el capítulo 1. Como podría esperar, los roles para el analista de sistemas cam-
bian sutilmente cuando se inician los proyectos, ya que el enfoque está en las oportunidades de mejorar en vez de
estar en la necesidad de resolver los problemas.
Definición del problema
Sin importar que utilice el SDLC clásico o una metodología orientada a objetos, el analista primero define los
problemas y objetivos en el sistema. Éstos forman la base para determinar qué debe lograr el sistema. Los méto-
dos como Seis Sigma (el capítulo 16 proporciona más información) empiezan con una definición del problema.
Revisar la salida y compararla con los
criterios de rendimiento.
Observar el comportamiento de
los empleados.
Escuchar la retroalimentación externa de:
Distribuidores
Clientes
Proveedores
Demasiados errores
El trabajo se completa con lentitud
El trabajo se hace en forma incorrecta
El trabajo se hace en forma incompleta
No se hace ningún trabajo
Niveles altos de ausentismo
Mucha inconformidad en el trabajo
Mucha rotación de empleados
Busque estas señales específicas:Para identificar los problemas
Quejas
Sugerencias para mejorar
Pérdida de ventas
Ventas más bajas
FIGURA 3.1
Comprobar la salida, observar el
comportamiento de los empleados
y escuchar la retroalimentación
son todas formas de ayudar al
analista a destacar los problemas y
oportunidades de sistemas.www.xlibros.com

58 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Por lo general, la definición de un problema contiene cierta clase de declaración del mismo, sintetizada en
uno o dos párrafos. A ésta le siguen una serie de cuestiones o piezas independientes importantes del problema.
Estas cuestiones van seguidas de una serie de objetivos o metas que coincidan con cada uno de los puntos es-
tablecidos en las cuestiones. Las cuestiones son la situación actual; los objetivos son la situación deseada. Los
objetivos pueden ser muy específicos o se pueden redactar mediante una declaración general.
He aquí algunos ejemplos de preguntas de negocios relacionadas con los objetivos de una empresa:
¿Cuáles son los propósitos de la empresa?
¿Es una empresa con o sin fines de lucro?
¿Planea la compañía crecer o expandirse?
¿Cuál es la postura de la empresa (cultura) en cuanto a la tecnología?
¿Cuál es el presupuesto que la empresa tiene asignado para la TI?
¿El personal de la empresa tiene la experiencia requerida?
Sobra decir que el analista de sistemas debe comprender la forma en que funciona la empresa.
La última parte de la definición del problema contiene los requerimientos, las cosas que se deben lograr,
junto con las posibles soluciones y las restricciones que limitan el desarrollo del sistema. La sección de requeri-
mientos puede incluir seguridad, capacidad de uso, requerimientos gubernamentales, etcétera. A menudo las res-
tricciones incluyen la palabra no para indicar una limitación, y pueden contener restricciones en el presupuesto o
límites de tiempo.
La definición del problema se produce después de terminar con las entrevistas, las observaciones y el aná-
lisis de los documentos con los usuarios. El resultado de recopilar esta información es una enorme cantidad de
hechos y opiniones importantes que debe sintetizarse. El primer paso para producir la definición del problema es
O P O R T U N I D A D D E C O N S U L T O R Í A 3 . 1
El sonido más dulce que haya sorbido
Félix Straw, quien representa a uno de varios distribuidores en
EE.UU., del refresco europeo Sipps, examina con desagrado el
mapa del clima en un periódico, donde la mayor parte de los Esta-
dos Unidos aparece cubierta del rojo oscuro que indica la anticipada
ola de calor primaveral, sin signos de que vaya a pasar. Apuntando
al diario, dice al grupo de sistemas al que usted pertenece: “Es lo
mejor que nos pudo ocurrir... o así debería ser. Pero cuando tuvi-
mos que colocar nuestros pedidos hace tres meses, ¡no teníamos
idea de que esta monstruosa ola de calor iba a devorar el país de esta
forma!”. Señalando con la cabeza una fotografía de la planta euro-
pea en la pared, continúa: “Tenemos que ser capaces de decirles
cuando las cosas se calienten por acá, para obtener suficiente pro-
ducto. De lo contrario perderemos todas las oportunidades. Esto
ocurrió hace dos años y casi nos eliminó del mercado”.
“Cada uno de nuestros distribuidores se reúne con nuestros ge-
rentes de distrito para realizar una planeación de tres meses. Cuando
estamos de acuerdo, enviamos nuestros pedidos a las oficinas gene-
rales en Europa. Ellos hacen sus propios ajustes, embotellan las bebi-
das y luego recibimos nuestros pedidos modificados entre 9 y 15
semanas más tarde. Pero necesitamos formas de decirles lo que está
ocurriendo ahora. Incluso hay varias supertiendas que están abriendo
aquí. Deben saber que tenemos una demanda muy alta”.
Corky, su asistente, asiente y dice: “Sí, por lo menos deberían
analizar nuestras ventas del año pasado en este periodo. Algunas
primaveras son calientes, otras no tanto”.
Straw coincide y dice: “Sería música para mis oídos, algo
realmente dulce, si pudieran trabajar con nosotros para detectar las
tendencias y los cambios, y después responder con rapidez”.
Stern’s, con base en Blackpool, Inglaterra, es un fabricante
europeo de bebidas, además de ser el desarrollador y productor de
Sipps, una bebida no carbonatada dulce, con sabor a frutas, sin al-
cohol, que se sirve fría y es muy popular cuando hace calor. Con
excelentes ventas en Europa y una popularidad en aumento en los
Estados Unidos desde su presentación cinco años atrás, Sipps ha
tenido dificultades para administrar el inventario en forma adecuada
y satisfacer la demanda de los clientes estadounidenses, que se ve
afectada por las fluctuaciones de temperatura estacionales del año.
Los lugares con clima cálido durante todo el año y muchos turistas
(como Florida y California) tienen grandes pedidos permanentes,
pero otras áreas del país se podrían beneficiar de un proceso de
pedidos menos incómodo y más receptivo. Sipps se distribuye a
través de una red de distribuidores locales esparcidos por todo
Estados Unidos y Canadá.
Como uno de los analistas de sistemas asignado para trabajar
con los distribuidores de Sipps en los EE.UU., empiece su análisis
haciendo una lista de algunos de los síntomas y problemas clave que
identificó después de estudiar los flujos de información, el proceso
de pedidos y la administración del inventario, y después de entre-
vistar al Sr. Straw y a su asistente. Describa en un párrafo los pro-
blemas que podrían indicar la necesidad de una solución de
sistemas.
Nota: Esta oportunidad de consultoría está inspirada en el artículo de J. C.
Pérez, “Heineken’s HOPS Software Keeps A-Head on Inventory”, PC Week,
Vol. 14, Núm. 2, enero 13, 1997, pp. 31 y 34.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 59
encontrar varios puntos que se puedan incluir en una cuestión. Los puntos importantes se pueden identificar en la
entrevista de distintas formas:
1. Los usuarios pueden identificar una cuestión, asunto o tema que se repita varias veces; en ocasiones pueden
ser distintas personas en varias entrevistas.
2. Los usuarios pueden comunicar las mismas metáforas, como decir que la empresa es un viaje, un juego de
guerra, un organismo, una máquina, etcétera.
3. Los usuarios pueden hablar mucho sobre un tema.
4. Los usuarios le pueden decir abiertamente: “Éste es un problema importante”.
5. Los usuarios pueden comunicar la importancia mediante el lenguaje corporal o hablar tajantemente sobre
una cuestión.
6. El problema puede ser lo primero que mencione el usuario.
Una vez creadas las cuestiones hay que declarar los objetivos. A veces, el analista debe realizar una entre-
vista de seguimiento para obtener información más precisa sobre los objetivos. Una vez declarados éstos, hay
que determinar la importancia relativa de las cuestiones o de los objetivos. Si no hay suficientes fondos para de-
sarrollar el sistema completo, primero es necesario completar los objetivos más críticos. Los usuarios son quie-
nes pueden identificar mejor los objetivos más críticos (con la ayuda de los analistas), ya que son expertos de
dominio en su área de negocios y saben cómo trabajar mejor con las tecnologías en la organización.
Una de las técnicas es pedir a los usuarios que asignen una ponderación para cada cuestión u objetivo del
primer borrador de la definición del problema. Es un juicio subjetivo por parte del usuario, pero si varios de
ellos asignan ponderaciones y se obtiene un promedio de todas, el resultado podría reflejar mejor la situación.
Después de determinar las ponderaciones se modifica la secuencia del orden de las cuestiones y objetivos de la
definición del problema en orden de mayor a menor importancia. Existe software como Expert Choice (www.
expertchoice.com) y otros paquetes de software de soporte de decisiones que pueden ayudar con los procesos de
pesar y asignar prioridades a los objetivos.
Además de analizar los datos y entrevistar personas, trate de presenciar el problema por su cuenta. Al anali-
zar la misma situación, tal vez un empleado pueda ver un problema en forma muy distinta a un analista de siste-
mas. Esto también ofrece a los analistas la oportunidad de confirmar sus hallazgos. De esta forma utilizan varios
métodos, con lo cual fortalecen el caso para tomar la acción apropiada.
UN EJEMPLO DE DEFINICIÓN DE PROBLEMA: EL SERVICIO DE BANQUETES CATHERINE. El Servicio de banquetes
Catherine es una pequeña empresa que provee servicios de alimentos, recepciones y banquetes para reuniones de
negocios y sociales como comidas formales y bodas. El amor de Catherine por la cocina y su talento para preparar
platillos finos inspiraron este negocio. Al principio era una pequeña empresa con unos cuantos empleados que
trabajaban en pequeños proyectos. Catherine se reunía con los clientes para determinar el número de personas,
el tipo de alimentos y demás información necesaria para dar servicio a un evento. Su reputación como excelente
proveedora de banquetes de alta calidad hizo aumentar su volumen de negocios. Gracias a la construcción de un
nuevo centro de convenciones y a la próspera comunidad comercial en la ciudad, aumentó el número de eventos
de servicio de banquetes.
Catherine administraba el negocio mediante el uso de hojas de cálculo y un procesador de palabras, pero se
le dificultaba estar al tanto de las interminables llamadas telefónicas sobre los tipos de comida disponibles, los
cambios en el número de invitados que iban a asistir al evento y la disponibilidad de artículos especiales, como
platillos de comida vegetariana, bajos en calorías o en carbohidratos, etc. La decisión de Catherine de contratar
varios empleados de medio tiempo para cocinar y ayudar en los eventos complicó la programación del personal,
proceso que estaba abrumando al nuevo gerente de recursos humanos. Catherine decidió contratar una empresa
de consultoría de TI y negocios para ayudarla a lidiar con los problemas a los que se enfrentaba su empresa de
servicio de banquetes.
Después de realizar varias entrevistas y observar al personal clave, los consultores encontraron las siguientes
cuestiones:
1. El chef principal hacía un pedido de provisiones por evento. Los proveedores podrían ofrecer descuentos si
se pidieran cantidades mayores de una sola vez para todos los eventos que se llevaran a cabo en cierto
periodo.
2. A menudo los clientes llamaban para cambiar el número de invitados para un evento, y algunos de esos
cambios se realizaban sólo uno o dos días antes del día programado para el evento.
3. Catherine y su personal requerían demasiado tiempo para atender cada solicitud de servicio;
aproximadamente el 60 por ciento de las llamadas terminaba contratando los servicios.
4. Algunas veces no había disponibilidad de empleados por conflictos de horario, y algunos eventos no
contaban con el suficiente personal. Las quejas sobre la puntualidad del servicio se estaban haciendo más
frecuentes.www.xlibros.com

60 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
5. Catherine no tiene información sintetizada en cuanto al número de eventos y los tipos de comidas. Sería
conveniente contar con información sobre las tendencias para ayudarle a guiar a sus clientes a la hora de
elegir sus platillos.
6. Por lo general, los eventos se llevan a cabo en hoteles u otros salones que proveen servicios de vajilla, mesas y
sillas. Hay problemas en cuanto a tener suficientes meseros debido a los cambios en el número de invitados.
La figura 3.2 muestra la definición del problema. Observe las ponderaciones a la derecha, las cuales repre-
sentan un promedio de las asignadas por cada empleado. Los objetivos coinciden con los problemas. Cada obje-
tivo se utiliza para crear los requerimientos de los usuarios.
Definición del problema
El Servicio de banquetes Catherine está experimentando problemas para atender el número de llamadas de rutina
de los clientes, así como para coordinarse con los proveedores externos de productos e instalaciones. El aumento
en el número de personal de medio tiempo está provocando conflictos en los horarios y eventos subatendidos.
Problema
1. El contacto del cliente toma una exorbitante cantidad de tiempo en las preguntas de rutina.
2. Administrar empleados de medio tiempo consume mucho tiempo y provoca conflictos en los horarios.
3. Es difícil tener en cuenta los cambios de último minuto en los eventos.
4. Se piden provisiones para cada evento. A menudo los envíos se reciben varias veces al día.
5. Con frecuencia hay problemas para comunicar los cambios a las instalaciones de los eventos.
6. Hay poca información histórica sobre los clientes y las comidas.
Objetivos
1. Proveer un sistema Web para que los clientes obtengan información sobre los precios y coloquen sus pedidos.
2. Crear o comprar un sistema de recursos humanos con un componente para programar horarios.
3. Una vez que los clientes hayan firmado un contrato para un evento, proveerles con acceso Web a su cuenta y
los medios para que actualicen el número de invitados. Notificar a la administración sobre estos cambios.
4. Proveer los medios para determinar las cantidades de provisiones requeridas por eventos que ocurran en forma
concurrente dentro de un periodo dado.
5. Proveer un sistema para comunicar los cambios al personal clave en las instalaciones de los eventos.
6. Almacenar todos los datos de los eventos y tener información sintetizada disponible en varios formatos.
Requerimientos
1. El sistema debe ser seguro.
2. Los gerentes de los eventos deben introducir la retroalimentación al momento de cerrar cada evento.
3. Debe haber un medio para que las instalaciones de los eventos puedan cambiar a la persona que servirá como contacto.
4. El sistema debe ser fácil de usar para personas sin conocimientos técnicos.
Restricciones
1. Los costos de desarrollo no deben exceder de $50,000.
2. El sitio Web inicial para los pedidos de los clientes deberá estar listo para el 1 de marzo, de manera que se
puedan atender las solicitudes de fiestas de graduación y bodas.
10
9
7
6
5
3
Ponderaciones
FIGURA 3.2
Definición del problema para Servicio de
banquetes Catherine, desarrollado con la
ayuda de algunos usuarios.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 61
Después, estos requerimientos se utilizan para crear casos de uso y un diagrama de casos de uso, o procesos
del diagrama de flujo de datos. Cada objetivo puede crear uno o más requerimientos de usuario o varios objetivos
pueden crear uno o tal vez ningún caso de uso (no es común crear casos de uso para informes simples), o cada
requerimiento puede crear un proceso de diagrama de flujo de datos. Los requerimientos de los usuarios para el
Servicio de banquetes de Catherine son:
1. Crear un sitio Web dinámico para permitir que los clientes actuales y potenciales obtengan información y
precios de los servicios y productos ofrecidos.
2. Permitir que los clientes actuales y potenciales envíen una solicitud con sus elecciones de servicio de
banquete, y que la solicitud se canalice a un gerente de cuentas.
3. Agregar clientes a la base de datos de clientes, asignarles un ID de usuario y una contraseña para que tengan
acceso a sus proyectos.
4. Crear un sitio Web para que los clientes puedan ver y actualizar el número de invitados para un evento, y restringir
los cambios al número de invitados cuando falten menos de cinco días para que se lleve a cabo el evento.
5. Obtener o crear software para comunicarse directamente con el personal de las instalaciones de los eventos.
6. Crear o comprar un sistema de recursos humanos para programar los horarios de los empleados de medio tiempo,
de manera que la administración pueda agregar empleados y programarlos mediante el uso de varias restricciones.
7. Proveer consultas o informes con información sintetizada.
Cada requerimiento se puede utilizar para crear un plan de prueba preliminar. Como al inicio hay pocos de-
talles disponibles, el plan de prueba se revisará a medida que avance el proyecto.
El siguiente podría ser un plan de prueba simple para el Servicio de banquetes de Catherine:
1. Diseñar datos de prueba que permitan a los clientes ver cada uno de los distintos tipos de productos.
2. Probar que efectivamente se haya introducido una solicitud de servicio de banquete con datos válidos, así
como cada una de las posibles condiciones de datos inválidos (definiremos los datos más adelante).
Asegúrese de que la solicitud se canalice al gerente de cuentas apropiado.
3. Probar que todos los campos de datos pasen todos los criterios de validación para cada campo. Probar datos
reales para asegurar que se agreguen los clientes a la base de datos de clientes y que se les asigne un ID de
usuario y una contraseña correctamente.
4. Crear un plan de prueba para verificar que los clientes puedan ver la información de los eventos. Probar que
no se puedan realizar actualizaciones cuando falten 5 días o menos para el evento. Diseñar datos de prueba
que permitan verificar que se actualice en forma correcta el número de invitados para un evento.
5. Probar que el software funcione correctamente para comunicarse en forma directa con el personal de las
instalaciones de los eventos.
6. Probar el sistema de recursos humanos para programar los horarios de los empleados de medio tiempo y
verificar que éstos se agreguen correctamente, además de verificar que se detecten y reporten todos los
valores inválidos para cada campo. Verificar que el software de programación de horarios realice
actualizaciones válidas y detectar las entradas inválidas.
7. Verificar que todas las consultas o informes funcionen correctamente y contengan la información de
resumen correcta.
Selección de proyectos
Los proyectos tienes orígenes distintos y se inician por muchas razones. No todos se deben seleccionar para
continuar su estudio. Como analista, usted debe tener razones muy claras para recomendar un estudio de siste-
mas en un proyecto que parezca resolver un problema o que pudiera dar lugar a una mejora. Tome en cuenta la
motivación detrás de una propuesta para el proyecto. Necesita estar seguro de que el proyecto en consideración
no se proponga sólo por mejorar su propia reputación o su poder ni el de la persona o grupo que lo propone, ya
que hay una buena probabilidad de que dicho proyecto sea mal concebido y que en un momento dado no sea
muy bien aceptado.
Como vimos en el capítulo 2, hay que examinar los proyectos que se tengan como prospectos desde una
perspectiva de sistemas, de tal forma que consideremos el impacto del cambio propuesto en toda la organización.
Recuerde que los diversos subsistemas de la organización están interrelacionados y son interdependientes, por lo
que un cambio en un subsistema podría afectar a los demás. Incluso cuando los encargados de tomar las decisio-
nes que están directamente involucrados son los que en última instancia establecen los límites para el proyecto
de sistemas, no podemos contemplar o seleccionar un proyecto de sistemas aislados del resto de la organización.
Además de estas consideraciones generales tenemos cinco criterios específicos para la selección de proyectos:
1. Contar con el respaldo de la administración.
2. Que sea el momento oportuno para comprometerse con el proyecto.www.xlibros.com

62 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
3. La posibilidad de mejorar la obtención de los objetivos de la organización.
4. Que sea práctico en términos de recursos para el analista de sistemas y la organización.
5. Que el proyecto valga la pena en comparación con las demás formas en que la organización podría invertir
sus recursos.
Antes que nada está el respaldo de la administración. No se puede lograr nada en absoluto sin el patrocinio
de las personas que en un momento dado tendrán que pagar la cuenta. Esto no significa que usted no tenga in-
fluencia para dirigir el proyecto o que no se puedan incluir otras personas aparte de la administración, pero sí que
su respaldo es esencial.
Otro criterio importante para la selección de un proyecto es que suceda en el momento oportuno para usted
y la organización. Pregúntese a sí mismo y a los demás involucrados si la empresa es capaz en esos momentos de
comprometerse con el tiempo requerido para la instalación de nuevos sistemas o para mejorar los sistemas exis-
tentes. Usted también debe ser capaz de comprometer todo su tiempo (o la parte necesaria del mismo) durante
este periodo.
Un tercer criterio es la posibilidad de mejorar el logro de los objetivos de la organización como 1) mejo-
rar las ganancias de la empresa, 2) brindar soporte a la estrategia competitiva de la organización, 3) mejorar la
cooperación con los distribuidores y socios, 4) mejorar el soporte a las operaciones internas de manera que los
productos y servicios se produzcan con eficiencia y efectividad, 5) mejorar el soporte a las decisiones internas de
manera que éstas sean más efectivas, 6) mejorar el servicio al cliente y 7) aumentar la moral de los empleados. El
proyecto debe encaminar a la organización hacia sus objetivos primordiales y no desviarla de ellos.
El cuarto criterio es seleccionar un proyecto que sea práctico en términos de sus recursos y capacidades, así
como las de la empresa. Algunos proyectos no estarán dentro de su área de experiencia, por lo cual debe ser ca-
paz de reconocerlos.
Por último, necesita llegar a un acuerdo básico con la organización en cuanto a si vale la pena el proyecto
de sistemas en comparación con cualquier otro posible proyecto que se esté considerando. Hay muchas posibi-
lidades para realizar mejoras como 1) agilizar un proceso, 2) optimizar un proceso por medio de la eliminación
de pasos innecesarios o duplicados, 3) combinar procesos, 4) reducir errores en la entrada por medio de cambios
en los formularios y las pantallas de visualización, 5) reducir el almacenamiento redundante, 6) reducir la salida
redundante y 7) mejorar la integración de los sistemas y subsistemas. Recuerde que cuando una empresa se com-
promete con un proyecto, está comprometiendo los recursos que podrían ya no estar disponibles para otros. Es
conveniente considerar que todos los posibles proyectos compiten por los recursos de tiempo, dinero y personal
de la empresa.
DETERMINACIÓN DE LA VIABILIDAD
Una vez que reducimos el número de proyectos de acuerdo con los criterios antes descritos, todavía falta deter-
minar si los proyectos seleccionados son viables. Nuestra definición de viabilidad va mucho más allá del uso
común del término, ya que existen tres formas principales para evaluar la viabilidad de los proyectos de sistemas:
en base a su operación, a su capacidad técnica y a su economía. El estudio de viabilidad no es un estudio deta-
llado de sistemas, sino que se utiliza para recopilar datos más generales para los miembros de la administración,
lo cual a su vez les permite tomar una decisión en cuanto a si deben continuar o no con un estudio de sistemas.
Los datos para el estudio de viabilidad se pueden recuperar a través de entrevistas, las cuales veremos con
detalle en el capítulo 4. El tipo de entrevista requerida está relacionado de manera directa con el problema u
oportunidad que se sugiere. Por lo general, el analista de sistemas entrevista a las personas que piden ayuda y
a las que están relacionadas en forma directa con el proceso de toma de decisiones, que generalmente son los
administradores. Aunque es importante abordar el problema correcto, el analista de sistemas no debe invertir
mucho tiempo en realizar estudios de viabilidad, ya que se solicitarán muchos proyectos y se podrán o deberán
llevar a cabo sólo unos cuantos. El estudio de viabilidad debe tardar el menor tiempo posible, procurando abarcar
varias actividades en un periodo de tiempo corto.
Determinar si es posible o no
Una vez que el analista determina objetivos razonables para un proyecto, necesita determinar si es posible que
la organización y sus miembros puedan ver el proyecto hasta su terminación. Por lo general, el proceso de eva-
luación de la viabilidad es efectivo para descartar proyectos inconsistentes con los objetivos de la empresa, que
requieran una capacidad técnica imposible o que no tengan ningún mérito económico.
Aunque es meticuloso, el estudio de la viabilidad es algo que vale la pena ya que ahorra tiempo y dinero a
las empresas y a los analistas de sistemas. Para que el analista pueda recomendar que se continúe con el desarro-
llo de un proyecto, éste debe mostrar que es viable en las tres siguientes formas: técnica, económica y operacio-
nal, como se muestra en la figura 3.3.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 63
VIABILIDAD TÉCNICA El analista debe averiguar si es posible desarrollar el nuevo sistema teniendo en cuenta los
recursos técnicos actuales. De no ser así, ¿se puede actualizar o complementar el sistema de tal forma que pueda
cumplir con lo que se requiere? Si no es posible complementar o actualizar los sistemas existentes, la siguiente
pregunta es si existe o no la tecnología que cumpla con las especificaciones.
Al mismo tiempo, el analista puede preguntar si la organización cuenta con el personal que tenga la habili-
dad técnica suficiente para lograr los objetivos. De no ser así, la pregunta es si pueden o no contratar programa-
dores, probadores, expertos o demás personal adicional que pueda tener habilidades de programación distintas a
las del personal existente, o si tal vez pueden subcontratar un tercero para que se haga cargo del proyecto. Otra
de las preguntas es si hay o no paquetes de software disponibles que puedan lograr sus objetivos, o si hay que
personalizar el software para la organización.
VIABILIDAD ECONÓMICA La viabilidad económica es la segunda parte de la determinación de recursos. Los
recursos básicos a considerar son el tiempo de usted como analista y el tiempo de su equipo de análisis de
sistemas, el costo de realizar un estudio de sistemas completo (incluyendo el tiempo de los empleados con los
que usted va a trabajar), el costo del tiempo del empleado de la empresa, el costo estimado del hardware y el
costo estimado del software o del desarrollo de software.
La empresa afectada debe ser capaz de ver el valor de la inversión que está considerando antes de compro-
meterse con un estudio de sistemas completo. Si los costos a corto plazo no se ven eclipsados por las ganancias a
largo plazo o no producen una reducción inmediata en los costos de operación, entonces el sistema no es econó-
micamente viable y el proyecto no debe continuar.
VIABILIDAD OPERACIONAL Suponga por un instante que tanto los recursos técnicos como económicos se
consideran adecuados. El analista de sistemas debe aún considerar la viabilidad operacional del proyecto
solicitado. La viabilidad operacional depende de los recursos humanos disponibles para el proyecto e implica la
acción de pronosticar si el sistema funcionará y se utilizará una vez instalado.
Si los usuarios están prácticamente casados con el sistema actual, no ven problemas con él y por lo general
no están involucrados en el proceso de solicitar un nuevo sistema, habrá mucha resistencia a la implementación
del nuevo. Las probabilidades de que se vuelva funcional en algún momento dado serán bajas.
Por otro lado, si los mismos usuarios han expresado la necesidad de un sistema que sea funcional por más
tiempo, de una forma más eficiente y accesible, hay más probabilidades de que el sistema solicitado se llegue a
utilizar en un momento dado. Gran parte del arte de determinar la viabilidad operacional recae en las interfaces
de usuario elegidas, como veremos en el capítulo 14.
DETERMINACIÓN DE LAS NECESIDADES DE HARDWARE Y SOFTWARE
Para evaluar la viabilidad técnica hay que evaluar la habilidad del hardware y software computacional para
manejar las cargas de trabajo en forma adecuada. En la figura 3.4 se muestran los pasos que sigue el analista de
sistemas para determinar las necesidades de hardware y software. En primer lugar, hay que realizar un inventario
de todo el hardware computacional con el que cuente la organización para descubrir qué hay disponible y qué se
puede utilizar.
El analista de sistemas necesita trabajar con los usuarios para determinar qué hardware se necesitará. Para
determinar el hardware necesario hay que determinar los requerimientos de información de los humanos. Tam-
bién puede ser útil conocer la estructura organizacional (como vimos en el capítulo 2) y la forma en que los
Los tres elementos clave de la viabilidad
Viabilidad técnica
Complemento para el sistema actual
Tecnología disponible para satisfacer las necesidades de los usuarios
Viabilidad económica
Tiempo del analista de sistemas
Costo del estudio de sistemas
Costo del tiempo de los empleados para el estudio
Costo estimado del hardware
Costo del software empaquetado o del desarrollo de software
Viabilidad operacional
Si el sistema funcionará o no cuando se instale
Si el sistema se utilizará o no
FIGURA 3.3
Los tres elementos clave de la
viabilidad: técnica, económica y
operacional.www.xlibros.com

64 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
usuarios interactúan con las tecnologías en el entorno organizacional al determinar el hardware necesario. Las
opciones en cuanto al hardware se pueden considerar sólo hasta que los analistas de sistemas, los usuarios y
la administración tengan una buena comprensión sobre los tipos de tareas que hay que llevar a cabo.
Hacer un inventario del hardware computacional
Empiece por hacer un inventario del hardware de computadora que ya esté disponible en la organización. En
un momento dado descubrirá que algunas de las opciones de hardware implican expandir o reciclar el hardware
actual, por lo que es importante saber qué hay disponible.
Si no hay un inventario de hardware actualizado disponible, el analista de sistemas necesita preparar uno rá-
pidamente y llevarlo a cabo. Como analista de sistemas, usted necesita saber lo siguiente:
1. El tipo de equipo: número de modelo y fabricante.
2. El estado de funcionamiento del equipo: sobre pedido, en funcionamiento, almacenado o por reparar.
3. La edad estimada del equipo.
4. La vida proyectada del equipo.
5. La ubicación física del equipo.
6. El departamento o persona que se considera responsable del equipo.
7. El arreglo financiero para el equipo: propio, alquilado o rentado.
Al determinar el hardware actual disponible se obtendrá un proceso de toma de decisiones más sólido para
el momento de realizar las decisiones sobre el hardware, ya que se eliminarán la mayor parte de las conjeturas
sobre lo que existe. Por medio de las entrevistas que usted haya realizado a los usuarios, los cuestionarios para
encuestarlos y la investigación de los datos de archivo, usted ya conocerá el nombre de personas disponibles para el
procesamiento de los datos, así como sus habilidades y capacidades. Use esta información para proyectar qué tan
bien se pueden satisfacer las necesidades del personal en cuanto a nuevo hardware.
Estimación de las cargas de trabajo
El siguiente paso para determinar las necesidades de hardware es estimar las cargas de trabajo. Para ello, los
analistas de sistemas formulan cifras que representan las cargas de trabajo actuales y pronosticadas para el sis-
tema, de manera que el hardware que se obtenga posea la capacidad de manejar las cargas de trabajo actuales y
futuras.
Pasos para adquirir hardware
y software computacional
Estimar las
cargas de trabajo
Evaluar
hardware
OpcionesCompra Comprar
COTS
Arrendamiento
Renta
Usar
ASP
Crear
Opciones
Evaluar
software
Adquirir el
equipo de
cómputo
Elegir el
distribuidor
Hacer inventario
del hardware
computacional
FIGURA 3.4
Pasos en la elección de hardware y
software.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 65
Si las estimaciones se realizan en forma apropiada, la empresa no tendrá que reemplazar hardware sólo debido
a un crecimiento imprevisto en el uso del sistema (sin embargo, otros eventos como las innovaciones tecnológicas
superiores pueden dictar el reemplazo de hardware, si la empresa desea mantener su ventaja competitiva).
Por necesidad, las cargas de trabajo se muestrean en vez de pasarlas a través de varios sistemas computacio-
nales. Los lineamientos que se proporcionan en el capítulo 5 se pueden usar en este caso también, ya que en el
muestreo de cargas de trabajo, el analista de sistemas toma una muestra de las tareas necesarias y los recursos
computacionales requeridos para completarlas.
La figura 3.5 comparara los tiempos requeridos por un sistema de información existente y uno propuesto,
los cuales deben manejar cierta carga de trabajo. Hay que tener en cuenta que en la actualidad la empresa utiliza
un sistema computacional antiguo para preparar un resumen de los embarques a sus almacenes de distribución
y que se está sugiriendo un tablero de control basado en Web. La comparación de la carga de trabajo analiza
cuándo y cómo se realiza cada proceso, cuánto tiempo humano se requiere y cuánto tiempo de computadora
se necesita. Hay que tener en cuenta que el sistema recién propuesto debería reducir en forma considerable el
tiempo humano y de computadora requeridos.
Evaluación del hardware computacional
Evaluar el hardware computacional es una responsabilidad que se comparte entre la administración, los usuarios
y los analistas de sistemas. Aunque los distribuidores suministrarán los detalles sobre sus ofrecimientos específi-
cos, los analistas deben supervisar el proceso de evaluación en forma personal, ya que tendrán siempre en cuenta
los mejores intereses para la empresa. Además los analistas de sistemas tal vez tengan que educar a los usuarios
y a la administración en cuanto a las ventajas y desventajas generales del hardware para que puedan ser capaces
de evaluarlo.
Con base en el inventario actual del equipo de cómputo y las estimaciones adecuadas de las cargas de tra-
bajo actuales y pronosticadas, el siguiente paso en el proceso es considerar los tipos de equipos disponibles que
Comparar el rendimiento de los
almacenes de distribución
mediante la ejecución del
programa para sintetizar datos
Se ejecutan los programas de
computadora cuando es necesario;
el procesamiento se realiza desde
la estación de trabajo
Las actualizaciones ocurren de
inmediato; el procesamiento se
realiza en línea
Gerente de distribución Gerente de distribución
A diario:
Introducir los embarques en hojas
de cálculo de Excel, verificar la
precisión de las hojas de datos
en forma manual y después
almacenar los archivos en medios
de respaldo
Por mes:
Ejecutar un programa que sintetice
los registros diarios y e imprima un
informe, obtener el informe y hacer
evaluaciones
A diario:
Introducir los embarques en el
sistema basado en Web mediante
cuadros desplegables. Los datos
se respaldan en forma automática
en la ubicación remota
Por mes:
Comparar almacenes en línea
mediante el tablero de control
de rendimiento; imprimir sólo si
es necesario
A diario : 20 minutos A diario: 10 minutos
Por mes: 30 minutos
Por mes: 30 minutos
Por mes: 10 minutos
Por mes: 10 minutos
A diario: 20 minutos A diario: 10 minutos
Tarea
Método
Personal
Cuándo y cómo
Requerimientos de
tiempo humano
Requerimientos de
tiempo de
computadora
Sistema existente Sistema propuesto
Comparar el rendimiento de los
almacenes de distribución en el
tablero de control basado en Web
FIGURA 3.5
Comparaciones de las cargas de
trabajo entre los sistemas
existentes y los propuestos.www.xlibros.com

66 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
parezcan cumplir con las necesidades proyectadas. La información de los distribuidores sobre los posibles sis-
temas y sus configuraciones se vuelve más pertinente en esta etapa, por lo cual hay que revisarla junto con la
administración y los usuarios.
Además, se pueden simular y ejecutar las cargas de trabajo en distintos sistemas, incluyendo los que la orga-
nización ya esté usando. Este proceso se conoce como “benchmarking”.
Los criterios que deben usar los analistas de sistemas y los usuarios para evaluar el rendimiento de distintos
sistemas en el hardware son:
1. El tiempo requerido para las transacciones promedio (incluyendo el tiempo requerido para introducir los
datos y cuánto se tarda en recibir la salida).
2. La capacidad del volumen total del sistema (cuánto se puede procesar al mismo tiempo antes de que surja un
problema).
3. El tiempo de inactividad de la CPU o red.
4. El tamaño de memoria provisto.
Algunos criterios se mostrarán en las demostraciones formales; otros no se pueden simular y hay que dedu-
cirlos de las especificaciones de los fabricantes. Es importante ser claro en cuanto a las funciones requeridas y
deseadas antes de involucrarse demasiado en los alegatos de los distribuidores durante las demostraciones.
Una vez que se conocen los requerimientos funcionales y se comprenden los productos actuales disponibles,
además de compararlos con lo que ya existe en la organización, los analistas de sistemas toman decisiones en
conjunto con los usuarios y la administración acerca de si es o no necesario obtener nuevo hardware. Podemos
considerar que las opciones existen en un continuo: desde usar sólo equipo que ya esté disponible en la empresa
hasta obtener equipo totalmente nuevo. Entre estos dos extremos existen varias opciones para realizar modifica-
ciones menores o mayores al sistema computacional existente.
TAMAÑO Y USO DE LAS COMPUTADORAS El rápido avance de la tecnología establece que el analista de sistemas
debe investigar los tipos de computadoras disponibles en el momento específico en que se escriba la propuesta de
sistemas. Los tamaños de las computadoras varían en forma considerable, desde los teléfonos celulares en
miniatura hasta las supercomputadoras del tamaño de un cuarto. Cada una tiene distintos atributos que debemos
considerar a la hora de decidir cómo implementar un sistema computacional.
Adquisición del equipo computacional
Las tres principales opciones para adquirir hardware computacional son comprarlo, arrendarlo o rentarlo. Hay
ventajas y desventajas que debemos considerar para cada una de las decisiones, como se muestra en la figura 3.6.
Algunos de los factores más influyentes a considerar para decidir cuál opción es la mejor para una instalación
en especial son: la comparación entre los costos iniciales y a largo plazo, si la empresa puede invertir o no capital en
equipo de cómputo y si desea tener el control completo y la responsabilidad sobre el equipo.
Ventajas Desventajas
• Más económico que arrendar o
rentar a largo plazo
• Habilidad de cambiar el sistema
• Provee ventajas fiscales por la
depreciación acelerada
• Control total
• No hay capital invertido
• No se requiere financiamiento
• Es fácil cambiar de sistemas
• Por lo general se incluyen el
mantenimiento y el seguro
• El costo inicial es alto
• Riesgo de obsolescencia
• Riesgo de quedar trabado si
la elección fue incorrecta
• Responsabilidad total
• La empresa no es dueña de
la computadora
• El costo es muy alto debido a
que el distribuidor asume el
riesgo (la opción más costosa)
Rentar
Comprar
Arrendar • No hay capital invertido
• No se requiere financiamiento
• Los arrendamientos son más
bajos que los pagos de renta
• La empresa no es dueña del
sistema cuando termina el
plazo de arrendamiento
• Por lo general hay una fuerte
multa si se termina el
arrendamiento antes de tiempo
• Los arrendamientos son más
costosos que las compras
FIGURA 3.6
Comparación de las ventajas y
desventajas de comprar, arrendar y
rentar equipo de cómputo.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 67
Comprar implica que la empresa será dueña del equipo. Uno de los principales factores determinantes para
comprar o no es la vida proyectada del sistema. Si el sistema se va a utilizar por más de cuatro o cinco años (y
se calcula que los demás factores se mantendrán constantes), la decisión por lo general será comprar. Observe en
el ejemplo de la figura 3.7 que el costo de comprar después de tres años es menor que el de arrendar o rentar.
A medida que los sistemas se hacen más pequeños y potentes, y menos costosos, y a medida que los sistemas
distribuidos se hacen más populares, cada vez más empresas deciden comprar equipo.
Arrendar el hardware de computadora en vez de comprarlo es otra de las posibilidades. Arrendar equipo al
distribuidor o a una empresa de arrendamiento de terceros es más práctico cuando la vida proyectada del sistema
es menor a cuatro años. Además, si se pronostican cambios considerables en la tecnología, arrendar es mejor
opción, ya que también permite a la empresa invertir su dinero en otro lado, donde pueda trabajar para ésta en
vez de estar invertido en equipos de capital. Sin embargo, durante un periodo extenso el arrendamiento no es una
manera económica de adquirir equipo de cómputo.
Rentar hardware de computadora es la tercera opción principal para adquirir computadoras. Una de las
principales ventajas de rentar es que no se tiene que invertir el capital de la empresa y, por ende, no se requiere
financiamiento. Además, al rentar el hardware computacional es más fácil cambiar el hardware del sistema. Por
último, es común que se incluyan el mantenimiento y el seguro en los contratos de renta. No obstante, debido a
los altos costos involucrados y al hecho de que la empresa no será dueña del equipo rentado, esta opción se debe
contemplar sólo como un movimiento a corto plazo para manejar las necesidades no recurrentes o limitadas de
computadoras, o en tiempos en los que la tecnología sea muy cambiante.
EVALUACIÓN DEL SOPORTE DE LOS DISTRIBUIDORES EN RELACIÓN CON EL HARDWARE DE COMPUTADORA Hay
que evaluar varias áreas clave al ponderar los servicios de soporte disponibles para las empresas por parte de los
distribuidores. La mayoría de los distribuidores ofrecen la prueba del hardware al momento de la entrega y una
garantía de 90 días que cubre cualquier defecto de fábrica, pero hay que averiguar qué más ofrece el distribuidor.
Con frecuencia, lo que distingue a los distribuidores de calidad es la amplia variedad de servicios de soporte que
ofrecen.
En la figura 3.8 se muestra una lista de los criterios clave que conviene verificar al evaluar el soporte de los
distribuidores. La mayoría de los servicios adicionales de soporte de los distribuidores que se muestran en esa
lista se negocian por separado de los contratos de arrendamiento o compra de hardware.
Los servicios de soporte incluyen el mantenimiento de rutina y preventivo del hardware, el tiempo de res-
puesta especificado (en menos de seis horas o al siguiente día hábil, por ejemplo) en caso de descomposturas del
equipo, el préstamo de equipo en caso de que haya que reemplazar el hardware de manera permanente o si se
requiere una reparación fuera del sitio, y la capacitación en el lugar de trabajo o seminarios de grupo fuera del
lugar de trabajo para los usuarios. Examine con detenimiento la descripción de servicios de soporte incluidas en
la compra o el arrendamiento del equipo, y recuerde involucrar al personal legal apropiado antes de firmar con-
tratos de equipos o servicios.
Desafortunadamente, evaluar el hardware de computadora no es tan simple como el hecho de comparar
costos y elegir la opción menos costosa. Algunas otras eventualidades que surgen comúnmente por parte de los
Arrendamiento mensual
× 36 meses
Subtotal
Pago inicial
$ 150
5,400
500
Arrendamiento
$5,900Costo total por 3 años
Precio de compra
Valor residual
$6,000
– 500
Compra
$5,500Costo total por 3 años
Renta mensual
× 36 meses
Costo total por 3 años
$ 170
$6,120
Renta
FIGURA 3.7
Comparación de las alternativas
para la adquisición de
computadoras.www.xlibros.com

68 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
usuarios y la administración incluye: 1) la posibilidad de agregar componentes al sistema si se requiere más
tarde, 2) la posibilidad de conectarse con equipo de otros distribuidores si el sistema necesita crecer, (3) los bene-
ficios de comprar más memoria según se requiera y (4) la estabilidad corporativa del distribuidor.
La competencia entre distribuidores ha originado la idea de producir hardware compatible con el de los
competidores para mejorar las probabilidades de supervivencia del distribuidor. Sin embargo, antes de quedar
convencido de que comprar compatibles más económicos es la forma de dotar a su sistema con capacidad mejo-
rada, investigue lo suficiente como para sentirse confiado de que el distribuidor original sea una entidad corpo-
rativa estable.
Evaluación de software
Los analistas y las organizaciones se enfrentan cada vez más con la decisión de crear, comprar o subcontratar al
evaluar software para los proyectos de sistemas de información, en especial cuando se contemplan actualizacio-
nes a sistemas existentes o antiguo.
Ya vimos las decisiones que toman los analistas entre rentar, comprar o arrendar hardware. Parte del proceso
de toma de decisiones relacionado con la compra de software comercial para venta en los canales convencionales
(COTS), la “renta” del software a un proveedor de servicios de aplicación (ASP) o la creación de software perso-
nalizado para el proyecto es análogo al proceso de decisión sobre el hardware.
Hay que recalcar que sin importar que usted desarrolle el software o compre un producto COTS para un pro-
yecto en especial, es imperativo completar primero un análisis de los requerimientos de información de los usua-
rios y los sistemas que utilizan (como vimos en los capítulos anteriores). Como analista, parte de la experiencia
que usted desarrolle consiste en formular juicios sólidos al decidir entre el desarrollo de software y comprar soft-
ware COTS para sistemas nuevos y existentes. En las siguientes secciones veremos cuándo es conveniente crear
su propio software, cuándo hay que comprar paquetes COTS y cuándo es mejor usar un ASP. En la figura 3.9 se
sintetizan las ventajas y desventajas de cada una de estas opciones.
CUÁNDO DEBEMOS CREAR SOFTWARE PERSONALIZADO Varias situaciones demandan la creación de software
original o de ciertos componentes de software. El caso más probable es cuando no existe software COTS o no se
puede identificar para la aplicación deseada. La alternativa es que el software tal vez exista, pero sea demasiado
costoso o no se pueda comprar o adquirir licencias con facilidad.
Hay que crear software original cuando la organización trata de obtener una ventaja competitiva por medio
del aprovechamiento de los sistemas de información. Éste es comúnmente el caso cuando una organización crea
aplicaciones de comercio electrónico u otras aplicaciones innovadoras sin que existiera algo así antes. También
es posible que la organización sea de las “primeras” en utilizar una tecnología específica o de su industria especí-
fica. Las organizaciones que tienen requerimientos muy especializados o que existen en industrias especializadas
también se pueden beneficiar del software original.
Las ventajas de crear su propio software incluyen ser capaz de responder a las necesidades especializadas de
usuarios y empresas, obtener una ventaja competitiva al crear software innovador, tener personal interno disponi-
ble para dar mantenimiento al software y el orgullo de poseer algo que usted ha creado.
Las desventajas de desarrollar su propio software incluyen el potencial de un costo inicial considerablemente
alto en comparación con la compra de software COTS o la subcontratación de un ASP, la necesidad de contratar
Línea completa de hardware
Productos de calidad
Garantía
Necesidades completas de software
Programación personalizada
Garantía
Compromiso con los itinerarios
Capacitación en la empresa
Asistencia técnica
Procedimientos de mantenimiento de rutina
Tiempo de respuesta especificado para las emergencias
Préstamo de equipo mientras se realiza la reparación
Detalles específicos que los
distribuidores ofrecen comúnmente
Soporte de hardware
Soporte de software
Instalación y capacitación
Mantenimiento
Servicios del distribuidor
FIGURA 3.8
Lineamientos para seleccionar
distribuidores.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 69
o trabajar con un equipo de desarrollo y el hecho de que usted sea responsable del mantenimiento continuo por
ser el creador del software.
CUÁNDO DEBEMOS COMPRAR SOFTWARE COTS El software comercial de venta en los canales convencionales
incluye productos como la suite de Microsoft Office, que a su vez incluye el programa Word para el
procesamiento de palabras, Excel para las hojas de cálculo, Access para crear bases de datos y otras aplicaciones.
Hay otros tipos de software COTS disponibles para sistemas a nivel organizacional en vez de uso personal o de
oficina. Algunos autores incluyen paquetes ERP populares (pero costosos) como Oracle y SAP en sus ejemplos
de software COTS. Estos paquetes tienen diferencias radicales en cuanto al grado de personalización, soporte y
mantenimiento requerido en comparación con Microsoft Office. El software COTS también se puede referir a los
componentes u objetos de software (también conocidos como bloques de construcción) que se pueden comprar
para proveer cierta funcionalidad necesaria en un sistema.
Considere el uso de software COTS cuando pueda integrar con facilidad las aplicaciones o paquetes a los
sistemas existentes o planeados, y cuando no haya identificado ninguna necesidad inmediata o continua de mo-
dificarlos o personalizarlos para los usuarios. Sus pronósticos deben demostrar que la organización para la cual
está diseñando el sistema muestra pocas probabilidades de pasar por cambios importantes después de la compra
propuesta de software COTS como un aumento considerable en los clientes o grandes expansiones físicas.
Hay algunas ventajas de comprar software COTS que usted debe tener en cuenta al momento de ponderar
las alternativas. Una de ellas es que estos productos se han refinado a través del proceso del uso y la distribución
comercial, por lo que a menudo se ofrecen funcionalidades adicionales. Otra ventaja es que por lo general, el
software empaquetado se prueba en forma exhaustiva y, por ende, es en extremo confiable.
A menudo el software COTS ofrece una funcionalidad mejorada, ya que es probable que un producto comer-
cial cuente con productos afiliados, características complementarias y actualizaciones que mejoren su atractivo.
Además, los analistas descubren con frecuencia que el costo inicial del software COTS es menor que el costo de
desarrollar software dentro de la empresa o usar un ASP.
Otra ventaja de comprar paquetes COTS es que muchas otras compañías también lo usan, por lo que los analis-
tas no tienen que experimentar con sus clientes a través de aplicaciones de software únicas. Por último, el software
Ventajas Desventajas
• Respuesta específica a las
necesidades especializadas de
la empresa
• La innovación puede dar a la
empresa una ventaja competitiva
• Personal interno disponible para
dar mantenimiento al software
• Orgullo de propiedad
• Puede tener un costo inicial
considerablemente alto en
comparación con el software
COTS o un ASP
• Es necesario contratar o trabajar
con un equipo de desarrollo
• Mantenimiento continuo
Creación de software
personalizado
• Las organizaciones que no se
especializan en sistemas de
información se pueden enfocar
en lo que hacen mejor (su misión
estratégica)
• No hay necesidad de contratar,
capacitar o retener una gran
cantidad de personal de TI
• No se gasta el tiempo de los
empleados en tareas de TI no
esenciales
• Pérdida de control de los datos,
sistemas, empleados de TI y
horarios de trabajo
• Preocupación sobre la viabilidad
financiera y estabilidad a largo
plazo del ASP
• Cuestiones de seguridad,
confidencialidad y privacidad
• Pérdida de ventaja corporativa
estratégica potencial en relación
con la capacidad de innovación
de las aplicaciones
Usar un ASP
• Refinado en el mundo comercial
• Mayor confiabilidad
• Mayor funcionalidad
• Por lo general tiene un menor
costo inicial
• Ya lo utilizan otras empresas
• La ayuda y capacitación se
incluyen con el software
• Enfocado en la programación,
no en la empresa
• Hay que acoplarse a las
características existentes
• Personalización limitada
• Futuro financiero incierto del
distribuidor
• Menor propiedad y compromiso
Comprar paquetes
COTS
FIGURA 3.9
Comparación de las ventajas y
desventajas de crear software
personalizado, comprar paquetes
COTS y subcontratar un ASP.www.xlibros.com

70 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
COTS cuenta con una ventaja en cuanto a la ayuda y la capacitación que se incluyen en la compra del software
empaquetado.
Como ejemplo del uso de software COTS, analicemos el caso de una compañía teatral, una organización sin
fines de lucro (generalmente, este tipo de asociaciones en especial las de artes escénicas tienden a atrasarse en
comparación con sus contrapartes con fines comerciales al adoptar tecnologías de comunicación de la informa-
ción (ICT)). Como es de esperarse, la compañía teatral se tardó en adoptar la Web. Cuando deseaban crear apli-
caciones de comercio electrónico, se vieron en la necesidad de contratar diseñadores externos para ello. En vista
de los gastos y la falta de experiencia interna, muchas organizaciones sin fines de lucro simplemente no pasaron
la parte comercial de sus organizaciones a la Web, y se quedaron en espera de paquetes de COTS como el soft-
ware de taquilla basado en PC, o ASP como las agencias de venta de boletos en línea que ya contaban con la au-
tomatización requerida, para poner estos servicios a disposición de los clientes. El desarrollo de software interno
estaba fuera de consideración para la mayoría de estos grupos, que por lo general tienen poco o nada de personal
de TI y un presupuesto reducido o inexistente, además de una mínima experiencia de TI interna.
Hay una desventaja en el uso de software COTS. Como no está diseñado para ser totalmente personalizado,
la compañía teatral no pudo incluir características clave en su base de datos de donadores con las que los usua-
rios contaban. Además, el software COTS también puede incluir errores que podrían exponer a la organización a
problemas legales relacionados con fallas en el servicio.
Hay que considerar otras desventajas en cuanto a la compra del software COTS, incluyendo el hecho de
que los paquetes están enfocados en la programación y no en los usuarios humanos que trabajan en una em-
presa. Además los usuarios deben acoplarse a las características existentes en el software, sin importar que sean
apropiadas o no. Una desventaja que surge de esto es la capacidad limitada de personalización de la mayoría del
software empaquetado. Otras desventajas incluyen la necesidad de investigar la estabilidad financiera del distri-
buidor del software y la sensación reducida de propiedad y compromiso que es inevitable cuando el software se
considera un producto y no un proceso.
Para obtener cierta perspectiva sobre los sistemas que se van a desarrollar, usted debe reconocer que más
de la mitad de los proyectos se construyen desde cero (en donde dos terceras partes utilizan métodos tradiciona-
les como SDLC y los prototipos, y una tercera parte utiliza tecnologías ágiles u orientadas a objetos). La mayor
parte de ellos se desarrollan mediante el uso de un equipo interno de análisis de sistemas. Los programadores
pueden ser internos o subcontratados.
Menos de la mitad de los proyectos se desarrollan a partir de aplicaciones o componentes ya existentes. La
gran mayoría se modifican, algunos en forma extensa. Menos del 5 por ciento del software es comercial que se
vende por canales convencionales y no requiere ningún tipo de modificación.
O P O R T U N I D A D D E C O N S U L T O R Í A 3 . 2
Veni, Vidi, Vendi (Vine, vi y vendí)
“ Es toda una elección. Es decir, ningún paquete individual pa-
rece tener todo lo que queremos, aunque algunos de ellos se acercan
mucho”, dice Roman, un ejecutivo de publicidad para Empire Ma-
gazine con quien usted ha estado trabajando en un proyecto de sis-
temas. Recientemente, ambos decidieron que el software empa-
quetado podría adaptarse a las necesidades del departamento de
publicidad y demoraría su declive general.
“La demostración de la última persona que vimos, el que tra-
bajaba para Data Coliseum, realmente era muy interesante. Y me
gusta su folleto. Impresión a todo color, en cartulina. Clásico.”,
afirmó Roman.
“¿Y qué hay sobre las personas de Vesta Systems? Son en verdad
dinámicos. Y su paquete es fácil de usar, sin complicaciones. Además
dijeron que capacitarían a todos los 12 , en el sitio de trabajo y sin costo.
Pero echa un vistazo a su publicidad: la imprimen en su oficina”.
Roman juguetea con su silla al tiempo que continúa su reseña
ad hoc del software y de los distribuidores del mismo. “Ese paquete
de Mars, Inc., realmente me convenció por sí solo. Es decir, tenía
un calendario integrado. Y me gusta la forma en que se podían elegir
todos los menús de las pantallas con base en números romanos.
Fácil. Y el distribuidor parece dispuesto a hacer una rebaja. Creo
que están en medio de una guerra de precios”.
“Pero ¿quieres saber cuál es mi favorito?”, pregunta Roman
con astucia. “El de Jupiter, Unlimited. Es decir, tiene todo, ¿verdad?
Cuesta un poco más pero hace lo que se necesita y la documenta-
ción es fabulosa. Desde luego que no ofrecen capacitación. Creen
que no se requiere”.
Usted ya está a punto de responderle a Roman que para presen-
tarle su decisión antes de la fecha límite del 15 de marzo, necesitará
evaluar tanto al software como a los distribuidores en forma siste-
mática. Evalúe a cada uno de los distribuidores y los paquetes con
base en lo que Roman ha dicho hasta ahora (suponga que puede
confiar en sus opiniones). ¿Cuáles son las predisposiciones de Ro-
man al evaluar software y los distribuidores? ¿Qué información
adicional necesita sobre cada empresa y su software antes de tomar
una decisión? Cree una tabla para evaluar a cada distribuidor. Res-
ponda a cada una de las preguntas en un párrafo separado.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 71
CUÁNDO DEBEMOS SUBCONTRATAR SERVICIOS DE SOFTWARE DE UN PROVEEDOR DE SERVICIOS DE APLICACIÓN Las
organizaciones pueden obtener ciertos beneficios al adoptar un enfoque completamente distinto para la obtención
de software. Esta tercera opción es la de subcontratar un proveedor de servicios de aplicación especializado en
aplicaciones de TI para que se encargue de algunas de las necesidades de software de la organización.
Hay beneficios específicos al subcontratar un proveedor de servicios de aplicación (ASP) para que se en-
cargue del desarrollo de las aplicaciones de la empresa. Por ejemplo, a las organizaciones que deseen retener su
enfoque estratégico y dedicarse a lo que saben hacer mejor, tal vez les convenga subcontratar un tercero para
producir aplicaciones de sistemas de información. Además, hacerlo implica que no hay que contratar, capacitar
y retener gran cantidad de personal de TI. Esto puede producir ahorros considerables. Cuando una organización
utiliza un ASP, se invierte una cantidad muy pequeña o nula del valioso tiempo de los empleados en las tareas de
TI no esenciales (ya que el ASP se encarga de ellas).
No hay que considerar la contratación de un ASP como una fórmula mágica para lidiar con los requerimien-
tos de software; hay desventajas que debemos considerar seriamente. Una de ellas es la pérdida general de control
sobre los datos corporativos, sistemas de información, empleados de TI e incluso el procesamiento y la programa-
ción de tiempos para el proyecto. Algunas empresas tienen la creencia de que su información es la parte central de
su negocio, por lo que tan sólo pensar en renunciar al control sobre ella es angustiante. Otra desventaja es la cues-
tión sobre la viabilidad financiera del ASP que se elija. También podrían existir cuestiones sobre la seguridad de
los datos y registros de la organización, además de la confidencialidad de los datos y la privacidad de los clientes.
Por último, al elegir un ASP se puede llegar a perder la ventaja corporativa estratégica que la organización pudo
haber obtenido al implementar por cuenta propia las aplicaciones innovadoras creadas por sus empleados.
EVALUACIÓN DEL SOPORTE DE LOS DISTRIBUIDORES EN RELACIÓN CON EL SOFTWARE Y LOS ASPS Ya sea que
compre un paquete COTS o contrate los servicios de ASP, de todas formas tendrá que lidiar con distribuidores
que antepongan sus propios intereses. Por tal motivo, usted debe estar dispuesto a evaluar el software con los
usuarios y evitar dejarse influenciar por los argumentos de venta de los distribuidores. En resumen, hay seis
categorías principales en las que se puede calificar el software, como se muestra en la figura 3.10: efectividad en
el rendimiento, eficiencia del rendimiento, facilidad de uso, flexibilidad, calidad de la documentación y soporte
del fabricante.
Poder realizar todas las tareas requeridas
Poder realizar todas las tareas deseadas
Pantallas de visualización bien diseñadas
Capacidad adecuada
Tiempo de respuesta rápido
Entrada eficiente
Salida eficiente
Almacenamiento de datos eficiente
Respaldo eficiente
Interfaz de usuario satisfactoria
Menús de ayuda disponibles
Archivos “Léame” para los cambios de último minuto
Interfaz flexible
Retroalimentación adecuada
Buena capacidad para recuperarse de los errores
Opciones para la entrada
Opciones para la salida
Se puede usar con otro software
Buena organización
Tutorial en línea adecuado
Sitio Web con sección de preguntas frecuentes (FAQ)
Línea directa de soporte técnico
Boletín de noticias/correo electrónico
Sitio Web en donde se pueden descargar las
actualizaciones del producto
Requerimientos de software Características específicas del software
Eficiencia del rendimiento
Efectividad en el rendimiento
Facilidad de uso
Flexibilidad
Calidad de la documentación
Soporte del fabricante
FIGURA 3.10
Lineamientos para la evaluación
del software.www.xlibros.com

72 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Evalúe el software usando datos de prueba de la empresa que lo está considerando y examine la documen-
tación que lo acompaña. No basta confiar sólo en las descripciones de los distribuidores. Por lo general, éstos
certifican que el software es funcional al momento en que sale de su establecimiento, pero no garantizarán que
esté libre de errores en cualquier situación o que no fallará cuando los usuarios realicen acciones incorrectas.
También es obvio que no garantizarán su software si se utiliza en conjunto con hardware defectuoso.
IDENTIFICACIÓN, PRONÓSTICO Y COMPARACIÓN
DE LOS COSTOS Y BENEFICIOS
Siempre hay que considerar los costos y beneficios del sistema computacional propuesto en conjunto, ya que es-
tán interrelacionados y a menudo son interdependientes. Aunque el analista de sistemas está tratando de proponer
un sistema que cumpla con varios requerimientos de información, las decisiones de continuar con el sistema pro-
puesto se basarán en un análisis de costos-beneficios y no en los requerimientos de información. Muchas veces
los beneficios se miden con base en los costos, como veremos en la siguiente sección.
Pronósticos
Los analistas de sistemas deben ser capaces de predecir ciertas variables clave antes de enviar su propuesta al
cliente. En cierto grado, un analista de sistemas tiene que depender de un análisis del tipo “qué pasaría si”. Por
ejemplo: “¿Qué pasaría si los costos de mano de obra aumentan sólo un 5 por ciento al año durante los próximos
tres años, en lugar de aumentar un 10 por ciento?”. Sin embargo, el analista de sistemas debe tener en cuenta que
no puede depender totalmente de estos análisis si quiere que su propuesta sea creíble, significativa y valiosa.
El analista de sistemas tiene a su disposición muchos modelos de pronósticos. La principal condición para
elegir un modelo es la disponibilidad de datos históricos. Si no hay datos disponibles, el analista debe recurrir a
uno de los siguientes métodos de juicio: estimaciones de la fuerza de ventas, encuestas para estimar la demanda
de los clientes, estudios Delphi (un pronóstico por consenso que un grupo de expertos desarrolla de manera inde-
pendiente a través de una serie de rondas), crear escenarios o bosquejar analogías históricas.
Si hay datos históricos disponibles, la siguiente diferenciación entre las clases de técnicas implica diferen-
ciar entre un pronóstico condicional o uno incondicional. En un pronóstico condicional hay una asociación entre
las variables en el modelo o de tal forma que exista una relación causal. Los métodos comunes en este grupo in-
cluyen: correlación, regresión, indicadores importantes, econometría y modelos de entrada/salida.
En el pronóstico incondicional el analista no tiene que buscar o identificar relaciones causales. En conse-
cuencia, los analistas de sistemas opinan que estos métodos son alternativas de bajo costo, fáciles de implemen-
tar. En este grupo se incluyen: el juicio gráfico, las medias móviles y el análisis de los datos en series de tiempo.
Como estos métodos son simples, confiables y efectivos en costo, en el resto de esta sección nos concentraremos
en ellos.
ESTIMACIÓN DE LAS TENDENCIAS Podemos estimar las tendencias de varias maneras. Una de ellas es mediante
el uso de una media móvil. Este método es útil debido a que es posible ajustar la consistencia de ciertos patrones
estacionales, cíclicos o aleatorios de forma que quede el patrón de tendencias. El principio detrás de las medias
móviles es calcular la media aritmética de los datos a partir de un número fijo de periodos; una media móvil de
tres meses es simplemente la media de los últimos tres meses. Por ejemplo, el promedio de las ventas para enero,
febrero y marzo se utiliza para predecir las de abril. Después se utilizan las ventas promedio de febrero, marzo y
abril para predecir las de mayo, y así sucesivamente.
Al momento de graficar los resultados podemos ver con facilidad que los datos con amplias fluctuaciones se
vuelven consistentes. El método de la media móvil es útil debido a su habilidad de uniformar los datos, pero al
mismo tiempo presenta muchas desventajas. Las medias móviles se ven afectadas más fuertemente debido a los
valores extremos que cuando se utiliza el método del juicio gráfico o cuando se realizan estimaciones mediante
otros métodos, como el de los mínimos cuadrados. El analista debe aprender a pronosticar con destreza, ya que a
menudo se obtiene información valiosa que puede incluso justificar todo el proyecto completo.
Identificación de los beneficios y costos
Podemos considerar los beneficios y costos como tangibles e intangibles. Al considerar los sistemas debemos
tener en cuenta ambos tipos de beneficios.
BENEFICIOS TANGIBLES Los beneficios tangibles son las ventajas que se pueden medir en dinero y se acumulan
en la organización a través del uso del sistema de información. Algunos ejemplos de beneficios tangibles son
aumento en la velocidad de procesamiento, acceso a información que se consideraba inaccesible por cualquier
otro método, acceso a la información de manera más oportuna, la ventaja que ofrece el poder de cálculo superior
de la computadora y la reducción en la cantidad de tiempo requerido por los empleados para completar ciertaswww.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 73
O P O R T U N I D A D D E C O N S U L T O R Í A 3 . 3
Vamos a ver a los magos
Elphaba I. Menzel y Glinda K. Chenoweth son los propietarios
de Paisajes Emerald City, un despacho de arquitectura de paisaje.
Están tratando de decidir entre 1) escribir su propio software, tal vez
mediante el uso de Microsoft Access como base; 2) adoptar un pa-
quete de software COTS, como QuickBooks Pro, o 3) contratar un
servicio conocido como Magos del Jardín, Inc., para que se encar-
guen de todas sus funciones contables.
Elphaba le pregunta a Glinda: “¿Es posible que podamos crear
nuestro propio sistema?”.
Glinda contesta: “Supongo que podríamos, pero nos llevaría
una eternidad. Tendríamos que definir todos nuestros campos, con-
sultas e informes. Necesitaríamos saber quién no nos ha pagado
todavía y cuánto tiempo ha transcurrido desde la última vez que le
cobramos”.
“Sí”, dice Elphaba, “y también tendríamos que crear descrip-
ciones de los productos, descripciones de los servicios y códigos
para todo lo que vendemos y proveemos”.
“Si eso fuera todo lo que necesitáramos, probablemente po-
dríamos hacerlo”, añade Glinda. “Pero también necesitamos incluir
un sistema de itinerarios. Necesitamos saber cuándo podemos pro-
veer los servicios a nuestros clientes y qué hacer cuando nos retra-
semos. Tal vez no valga la pena”.
“Aun así”, reflexiona Glinda, “mi madre solía decir ‘No hay
lugar como el hogar’. Tal vez no haya software como el que crea
uno mismo”.
“Estás viendo los dos lados de todo”, comenta Elphaba. “Pero
la ruta que quieres tomar es demasiado larga y riesgosa. Necesita-
mos un paquete de software listo para usar ahora. He oído acerca de
productos conocidos como software comercial de venta en canales
convencionales, el cual podemos comprar y adaptar a nuestro nego-
cio de servicios de jardín. Voy a investigar”. Así, Elphaba se apre-
sura a buscar software que pueda ser adecuado.
“Encontré algo”, grita Elphaba. “Encontré este software lla-
mado QuickBooks Pro en www.quickbooks.com y parece que po-
demos pagarlo. Hay muchas versiones ya del software: una para
contabilidad, otra para construcción, otra para servicios de la salud.
Tal vez podamos encontrar un paquete adecuado para nosotros. Y si
no, parece que podemos personalizar la versión genérica de Quick-
Books Pro para adaptarla a nuestras necesidades”.
“Además, nuestro sistema podría crecer. QuickBooks Pro es
escalable de antemano. Podemos agregar clientes, proveedores o
productos fácilmente. Sólo quería plantearte la idea de comprar un
paquete ya listo para usar”.
“Es interesante”, dice Glinda, “pero he estado investigando
por mi cuenta también. Algunos de nuestros competidores me dije-
ron que una empresa se encarga de todo el trabajo por ellos. Se
llama Magos del Jardín. Hacen paisajes, pero además mantienen
paquetes de cuentas por cobrar y de itinerarios”.
Así, fueron a ver a los Magos.
Joel Green, el propietario y creador de Magos del Jardín, está
orgulloso de su software. “Invertí una gran cantidad de tiempo tra-
bajando con mis proveedores, es decir, los viveros en el área, y
hemos desarrollado un sistema para codificación para todo”, alar-
dea. “Todos los árboles, los tamaños de los árboles, los arbustos, las
flores, el mantillo e incluso las herramientas para cuidar jardines
tienen números”.
“Empecé con una empresa pequeña, pero cuando los clientes
se enteraron de que había puesto atención al más mínimo detalle,
mi negocio floreció”. Y agrega: “Mis proveedores están enamora-
dos de mi sistema debido a que reduce la confusión”.
“Me di cuenta de que mis competidores trabajaban con los
mismos proveedores, pero no recibían un trato preferencial debido
a que no podían comunicar los detalles sobre los productos con
mucha efectividad. Entonces decidí que ofrecería mi software por
contrato. Ganaría dinero al rentar mi software y exigiría un mayor
respeto de mis proveedores. Mi acuerdo de licencia para el usuario
final establece que yo soy dueño del software, los códigos de los
productos y los datos generados por el sistema”.
“Mediante el uso de mi software único de los Magos puedo
personalizar un poco el paquete para el cliente, pero en esencia todos
los servicios de jardinería en el estado utilizarán mi base de datos,
códigos y funciones B2B. Daré mantenimiento a mi propio software.
Si pudieran ver el código, parecería un jardín con manicure”.
Ahora Glinda y Elphaba están más confundidas que antes.
Tienen tres opciones distintas: crear un paquete por su cuenta,
comprar software comercial de venta en los canales convencionales
tal como QuickBooks Pro, o subcontratar a los Magos del Jardín
para que satisfagan sus necesidades. Ayúdelas a que conozcan el
verdadero secreto de la felicidad (del software) al expresar las
ventajas y desventajas de cada una de sus alternativas. ¿Qué les
recomendaría usted? Escriba en dos párrafos una recomendación
con base en lo que usted considere con respecto a su situación de
negocios específica.
tareas. Y todavía quedan muchos ejemplos más. Aunque no siempre es fácil, podemos medir los beneficios
tangibles en términos de ahorro de dinero, recursos o tiempo.
BENEFICIOS INTANGIBLES Algunos beneficios que se acumulan en la organización debido al uso del sistema
de información son difíciles de medir pero no dejan de ser importantes. A estos se les conoce como beneficios
intangibles.
Entre los beneficios intangibles figuran un proceso de toma de decisiones mejorado, una mejoría en la preci-
sión, la empresa se vuelve más competitiva en el servicio al cliente, mantiene una buena imagen comercial y au-
menta la satisfacción en el trabajo para los empleados al eliminar las tareas tediosas. Como podemos ver en esta
lista, los beneficios intangibles son en extremo importantes y pueden tener implicaciones de largo alcance para la
empresa, ya que se relacionan con personas tanto en el exterior como en el interior de la organización.
Aunque los beneficios intangibles de un sistema de información son factores importantes que debemos con-
siderar al momento de decidir si continuamos con un proyecto de sistemas o no, un sistema que se construyawww.xlibros.com

74 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
teniendo en cuenta sólo sus beneficios intangibles no tendrá éxito. Usted debe hablar sobre los beneficios tan-
gibles e intangibles en su propuesta, ya que esto permitirá a los encargados de tomar las decisiones realizar una
decisión bien informada en relación con el sistema propuesto.
COSTOS TANGIBLES Los conceptos de costos tangibles e intangibles son paralelos a los conceptos de los
beneficios tangibles e intangibles que vimos antes. Los costos tangibles son aquellos que el analista de sistemas
y el personal contable de la empresa pueden pronosticar con precisión.
Entre los costos tangibles se incluye el costo del equipo como las computadoras y terminales, el costo de los
recursos, el costo del tiempo del analista de sistemas, el costo del tiempo de los programadores y los salarios de
los demás empleados relacionados. Por lo general, estos costos están bien establecidos o se pueden descubrir con
mucha facilidad, y son los que requerirán un desembolso de efectivo por parte de la empresa.
COSTOS INTANGIBLES Los costos intangibles son difíciles de estimar y tal vez no se conozcan. Entre éstos se
incluyen perder la ventaja competitiva, perder la reputación de ser el primero con una innovación o el líder en
un campo, reducir la imagen de la empresa debido al aumento en la inconformidad de los clientes, y un proceso
inefectivo de toma de decisiones debido a que la información pertinente se recibe después de tiempo o no se
tiene acceso a ella. Como podrá imaginar, es casi imposible pronosticar un monto de dinero para los costos
intangibles de una manera precisa. Para ayudar a los encargados de la toma de decisiones que desean ponderar
el sistema propuesto y todas sus implicaciones, usted debe incluir los costos intangibles incluso cuando no sean
cuantificables.
Comparación de los costos y beneficios
Existen muchas técnicas reconocidas para comparar los costos y beneficios del sistema propuesto. Entre éstas se
incluyen: análisis de punto de equilibrio, retribución, análisis de flujo de efectivo y análisis del valor presente.
Todas estas técnicas proveen formas simples y directas para ceder información a los encargados de tomar las
decisiones en cuanto al mérito del sistema propuesto.
ANÁLISIS DE PUNTO DE EQUILIBRIO Al comparar los costos por sí solos, el analista de sistemas puede utilizar el
análisis de punto de equilibrio para determinar la capacidad de punto de equilibrio del sistema de información
propuesto. El punto en el que los costos totales del sistema actual y los del sistema propuesto se cruzan representa
el punto de equilibrio, es decir, donde es rentable para la empresa obtener el nuevo sistema de información.
Los costos totales incluyen los que aparecen en forma recurrente durante la operación del sistema más los
costos de desarrollo que ocurren sólo una vez (costos únicos de instalación del nuevo sistema); es decir, los cos-
tos tangibles que acabamos de ver. En la figura 3.11 hay un ejemplo de un análisis de punto de equilibro para
una pequeña tienda que mantiene su inventario mediante un sistema manual. A medida que se eleva el volumen,
los costos del sistema manual se elevan en una tasa incremental. Un nuevo sistema computacional costaría una
Costo
($) Sistema
propuesto
Punto de
equilibrio
Sistema
actual
10,000
20,000
30,000
40,000
50,000
60,000
70,000
0
0 200 400 600 800 1,000 1,200
Unidades vendidas
Costo del sistema
propuesto
Costo del
sistema actual
Equipo de AnnieFIGURA 3.11
Análisis de punto de equilibrio
para el sistema de inventario
propuesto.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 75
buena suma de dinero al inicio, pero los costos incrementales por un volumen mayor serían bastante bajos. La
gráfica muestra que el sistema computacional sería efectivo en costo para la empresa si vendiera aproximada-
mente 600 unidades por semana.
El análisis del punto de equilibrio es útil cuando una empresa está creciendo y el volumen es una variable
clave en los costos. Una desventaja de este análisis es que se basa en la suposición de que los beneficios perma-
necen iguales, sin importar el sistema que se utilice. Con base en nuestro estudio de los beneficios tangibles e
intangibles sabemos que en definitiva no puede ser así.
El análisis del punto de equilibrio también puede determinar cuánto tiempo tardarán los beneficios del sis-
tema en retribuir los costos de su desarrollo. En la figura 3.12 se muestra un sistema con un periodo de retribu-
ción de tres y medio años.
ANÁLISIS DEL FLUJO DE EFECTIVO En este análisis se examina la dirección, el tamaño y el patrón del flujo de
efectivo asociado con el sistema de información propuesto. Si usted va a proponer el reemplazo de un antiguo
sistema de información por uno nuevo y el nuevo sistema no generará efectivo adicional para la empresa, sólo
hay desembolsos de efectivo asociados con el proyecto. En tal caso no podrá justificar el nuevo sistema con base
en la generación de nuevos ingresos y deberá examinarlo de cerca para encontrar otros beneficios tangibles si
desea que su propuesta tenga éxito.
En la figura 3.13 se muestra un análisis de flujo de efectivo para una pequeña empresa que provee servicios
de correo a otras pequeñas compañías en la ciudad. Las proyecciones de los ingresos son de sólo $5,000 en el
primer trimestre, pero después del segundo, los ingresos aumentarán con una tasa fija. Los costos serán mayores
en los primeros dos trimestres y luego se estabilizarán. El análisis de flujo de efectivo se utiliza para determinar
cuándo empezará una empresa a obtener ganancias (en este caso es en el tercer trimestre, con un flujo de efectivo
de $7,590) y cuándo “saldrá de la red”; es decir, cuando los ingresos compensan la inversión inicial (en el primer
trimestre del segundo año, cuando el flujo de efectivo acumulado cambia de un monto negativo a una cantidad
positiva de $10,720).
El sistema propuesto debe traer consigo un aumento en los ingresos como contraparte de los desembolsos de
efectivo. Por tanto, hay que analizar el tamaño del flujo de efectivo junto con los patrones asociados con la com-
pra del nuevo sistema. Hay que averiguar cuándo ocurrirán los desembolsos de efectivo y los ingresos, no sólo
para la compra inicial sino durante toda la vida del sistema de información.
ANÁLISIS DEL VALOR PRESENTE Este análisis ayuda al analista de sistemas a presentar, a los encargados de tomar
las decisiones en la empresa, el valor en tiempo de la inversión en el sistema de información así como el flujo de
efectivo (como vimos en la sección anterior). El valor presente es una forma de evaluar todos los desembolsos
económicos y los ingresos del sistema de información durante su vida económica, y de comparar los costos
actuales con los futuros, al igual que los beneficios actuales con los beneficios futuros.
En la figura 3.14, el total de costos del sistema es de $272,000 durante seis años y el total de beneficios es
de $280,700. Por lo tanto, podríamos concluir que los beneficios sobrepasan a los costos. Sin embargo, los bene-
ficios empezaron a sobrepasar a los costos hasta después del cuarto año y el monto en el sexto año no podrá ser
equivalente al monto en el primer año.
Costo
($)
Costos
Beneficios
10,000
20,000
30,000
40,000
50,000
60,000
70,000
0
0
1
2
3
4
5
6
Año Costo
($)
Costos
acumulados
($)
Beneficios
acumulados
($)
Beneficios
($)
30,000
1,000
2,000
2,000
3,000
4,000
4,000
30,000
31,000
33,000
35,000
38,000
42,000
46,000
0
12,000
12,000
8,000
8,000
10,000
15,000
0
12,000
24,000
32,000
40,000
50,000
65,000
0 1 2 3 4 5 6
Año
Beneficios acumulados
del sistema propuesto
Costos acumulados
del sistema propuesto
Periodo de
retribución
FIGURA 3.12
El análisis del punto de equilibrio
muestra un periodo de retribución
de tres años y medio.www.xlibros.com

76 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Ingresos
Costos
Año 1
Trimestre 2 Trimestre 3 Trimestre 4 Trimestre 1Trimestre 1
Año 2
$5,000 $20,000 $24,960 $31,270 $39,020
Desarrollo
de software
Personal
Capacitación
Arrendamiento
de equipo
Provisiones
Mantenimiento
10,000
8,000
3,000
4,000
1,000
0
26,000
5,000
8,400
6,000
4,000
2,000
2,000
27,400
8,800
4,000
2,370
2,200
17,370
9,260
4,000
2,990
2,420
18,670
9,700
4,000
3,730
2,660
20,090
Flujo de efectivo
Flujo de efectivo
acumulado
–21,000
–21,000
–7,400
–28,400
7,590
–20,810 –8,210
12,600
10,720
18,930
Costos totales
FIGURA 3.13
Análisis de flujo de efectivo para
el sistema de correos
computarizado.
1 2 3 4 5 6 Total
Año
$40,000
$25,000
42,000
31,200
44,100
39,000
46,300
48,700
48,600
60,800
Costos
Beneficios
51,000
76,000
272,000
280,700
FIGURA 3.14
Sin considerar el valor presente,
los beneficios parecen sobrepasar
a los costos.
1 2 3 4 5 6 Total
Año
$40,000
.89
35,600
$25,000
.89
22,250
42,000
.80
33,600
31,200
.80
24,960
44,100
.71
31,311
39,000
.71
27,690
46,300
.64
29,632
48,700
.64
31,168
48,600
.57
27,702
60,800
.57
34,656
51,000
.51
26,010
76,000
.51
38,760 179,484
183,855
Valor presente de los beneficios
Multiplicador
Valor presente de los costos
Multiplicador
Costos
Beneficio
FIGURA 3.15
Tomando en cuenta el valor presente, la conclusión es que los costos son mayores que los beneficios. Nos basamos en la suposición de que la
tasa de descuento i es de 0.12 para calcular los multiplicadores en esta tabla.
Por ejemplo, una inversión en dólares al 7 por ciento actual valdría $1.07 al final del año y se duplicaría en
aproximadamente 10 años. Por lo tanto, el valor actual es el costo del beneficio calculado en dólares actuales y
depende del costo del dinero. El costo del dinero es el costo de oportunidad, o la tasa que se obtendría si el di-
nero invertido en el sistema propuesto se invirtiera en otro proyecto (relativamente seguro).
Para calcular el valor presente de $1.00 a una tasa de descuento de i se determina el siguiente factor:
1
11 + i 2n
en donde n es el número de periodos. Después se multiplica el factor por la cantidad en dólares para obtener el
valor presente, como se muestra en la figura 3.15. En este ejemplo, nos basamos en la suposición de que el costo
del dinero —la tasa de descuento— es de 0.12 (12 por ciento) durante todo el horizonte de planificación. Se calcu-
lan multiplicadores para cada periodo: n 1, n 2, ..., n 6. Después se calculan los valores presentes de loswww.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 77
costos y los beneficios mediante estos multiplicadores. Después de realizar ese paso, los beneficios totales (me-
didos en dólares actuales) son de $179,484 y por ende son menores que los costos (también medidos en dólares
actuales). La conclusión que obtenemos es que el sistema propuesto no vale la pena si tenemos en cuenta el valor
presente.
Aunque este ejemplo en el que se utilizaron factores de valor presente es útil para explicar el concepto, todas
las hojas de cálculo electrónicas incluyen la función del valor presente. El analista puede calcular directamente el
valor presente mediante esta función.
LINEAMIENTOS PARA EL ANÁLISIS El uso de los métodos descritos en las subsecciones anteriores depende de los
métodos empleados y aceptados en la misma organización. Sin embargo, como lineamientos generales podemos
decir lo siguiente:
1. Use el análisis del punto de equilibrio si hay que justificar el proyecto en términos de costos y no de
beneficios, o si los beneficios no mejoran en forma considerable con el sistema propuesto.
2. Use la retribución cuando el aumento en los beneficios tangibles forme un argumento convincente para el
sistema propuesto.
3. Use el análisis de flujo de efectivo cuando el proyecto sea costoso con relación al tamaño de la empresa o
cuando ésta se vea afectada en forma considerable si hay que desembolsar una gran cantidad de fondos
(incluso si esto es temporal).
4. Use el análisis del valor presente cuando el periodo de retribución sea largo o cuando el costo de pedir
dinero prestado sea alto.
Cualquiera que sea el método elegido, es importante recordar que el análisis de costo-beneficio se debe abordar
de una manera sistemática que se pueda explicar y justificar a los gerentes, quienes decidirán en última instancia
si van a comprometer o no los recursos en el proyecto de sistemas. Ahora veamos la importancia de comparar
muchas alternativas de sistemas.
PLANEACIÓN Y CONTROL DE ACTIVIDADES
El análisis y diseño de sistemas involucra muchos tipos de actividades que en conjunto forman un proyecto. El
analista de sistemas debe administrar el proyecto con cuidado si quiere que tenga éxito. La administración de
proyectos incluye las tareas generales de planeación y control.
La planeación incluye todas las actividades requeridas para seleccionar un equipo de análisis de sistema, asignar
miembros del equipo a los proyectos apropiados, estimar el tiempo requerido para completar cada tarea y programar
el proyecto de manera que las tareas se completen a tiempo. El control implica utilizar retroalimentación para super-
visar el proyecto, incluyendo una comparación del plan para el proyecto con su evolución actual. Además, el control
implica tomar la acción apropiada para agilizar o reprogramar las actividades de manera que se puedan terminar a
tiempo, a la vez que se motiva a los miembros del equipo para que completen el trabajo en forma apropiada.
Estimación del tiempo requerido
La primera decisión del analista de sistemas es determinar el nivel de detalle para definir las actividades. El
menor nivel de detalle es el SDLC en sí, mientras que el extremo más alto es incluir cada paso detallado. La res-
puesta óptima para la planeación y programación está en algún lado entre estos dos extremos.
Aquí es conveniente usar una metodología estructurada. En la figura 3.16, el analista de sistemas que empieza
un proyecto ha descompuesto el proceso en tres fases importantes: análisis, diseño e implementación. Después, la
Fase Actividad
Análisis Recopilación de datos
Análisis de flujo de datos y decisiones
Preparación de la propuesta
Diseño Diseño de la entrada de datos
Diseño de las entradas
Diseño de las salidas
Organización de los datos
Implementación Implementación
Evaluación
Descomponer
las principales
actividades en
otras más
pequeñas.
FIGURA 3.16
Para empezar a planear un
proyecto hay que descomponerlo
en tres actividades principales.www.xlibros.com

78 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
fase de análisis se descompone aún más en recopilación de datos, análisis de flujo de datos y decisiones, y la prepa-
ración de la propuesta. El diseño se descompone en diseño de la entrada de datos, diseño de las entradas y las sali-
das y organización de los datos. La fase de implementación se divide en implementación y evaluación.
En los pasos subsiguientes, el analista de sistemas necesita considerar cada una de estas tareas y descom-
ponerlas más, de manera que se pueda llevar a cabo la planeación y programación de las mismas. En la figura 3.17
O P O R T U N I D A D D E C O N S U L T O R Í A 3 . 4
Alimento para el pensamiento
“ Realmente podríamos hacer algunos cambios. Sacudir a algu-
nas personas. Hacerles saber que estamos con eso. Me refiero al
aspecto tecnológico”, dice Malcolm Warner, vicepresidente de All-
Fine Foods, un distribuidor de productos lácteos al mayoreo. “Hay
que revisar y reparar ese antiguo sistema. Pienso que deberíamos
decir al personal que es tiempo de cambiar”.
“Sí, pero ¿qué deberíamos estar mejorando?” pregunta Kim
Han, asistente del vicepresidente. “Es decir, no hay problemas sus-
tanciales con la entrada o salida del sistema que pueda ver”.
Malcolm chasquea los dedos y dice: “Kim, estás ignorando
deliberadamente mi punto de vista. Afuera las personas nos ven
como una empresa aburrida. Un nuevo sistema computacional po-
dría cambiar eso. Cambiar la apariencia de nuestras facturas. Enviar
informes más llamativos a los propietarios de las cafeterías y res-
taurantes. Destacar como líderes en la distribución de alimentos y
las computadoras”.
“Bueno, con base en lo que he visto a través de los años”,
Kim responde sin alterar la voz, “un nuevo sistema es muy perju-
dicial, incluso si la empresa realmente lo necesita. A las personas
les disgustan los cambios, y si el sistema está funcionando como
debe, tal vez haya otras cosas que debamos hacer para actualizar
nuestra imagen sin que todos se vuelvan locos en el proceso. Ade-
más, estás hablando de muchos billetes verdes para un nuevo truco
publicitario”.
Malcolm dice: “No creo que con sólo lanzar una moneda aquí
entre nosotros dos vayamos a resolver algo. Revísalo y volvemos a
discutirlo. ¿No sería maravilloso?”.
Una semana después, Kim entra en la oficina de Malcolm con
varias páginas de notas de entrevistas en la mano. “Hablé con la mayor
parte de las personas que tienen mucho contacto con el sistema. Están
felices, Malcolm. Y no sólo hablan por hablar. Saben lo que hacen”.
“Estoy seguro de que a los gerentes les gustaría tener un sis-
tema más reciente que nuestros amigos de Quality Foods”, res-
ponde Malcolm. “¿Hablaste con ellos?”.
Kim le contesta: “Sí. Y están satisfechos”.
“¿Y qué hay sobre los de sistemas? ¿Te dijeron que la tecnolo-
gía para actualizar nuestro sistema está ahí afuera?”, pregunta
Malcolm con insistencia.
“Sí. Claro que se puede hacer. Pero eso no significa que se
deba hacer”, dice Kim con firmeza.
Como analista de sistemas para AllFine Foods, ¿cómo evalua-
ría usted la viabilidad del proyecto de sistemas que propone Mal-
colm? Con base en lo que dijo Kim sobre los gerentes, usuarios y
encargados de sistemas, ¿cuál parece ser la viabilidad operacional
del proyecto propuesto? ¿Qué hay sobre la viabilidad económica?
¿Y la viabilidad tecnológica? Con base en lo que discutieron Kim y
Malcolm, ¿recomendaría usted que se realizara un estudio detallado
de sistemas? Escriba su respuesta en un párrafo.
8
y después
estimar el
tiempo requerido.
Realizar entrevistas
Administrar cuestionarios
Leer informes de la compañía
Introducir el prototipo
Observar las reacciones al prototipo
Analizar el flujo de datos
Realizar el análisis de costo-beneficio
Preparar la propuesta
Presentar la propuesta
Recopilación de datos
Análisis de flujo de datos y decisiones
Preparación de la propuesta
3
4
4
5
3
3
2
2
Semanas
requeridasActividad detalladaActividad
Descomponer
éstos incluso
aún más
FIGURA 3.17
Para refinar la planeación y
programación de las actividades
de análisis hay que agregar tareas
detalladas y establecer el tiempo
requerido para completarlas.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 79
se muestra una descripción más detallada de la fase de análisis. Por ejemplo, la recopilación de datos se des-
compone en cinco actividades, desde realizar entrevistas hasta observar las reacciones al prototipo. Este pro-
yecto en especial requiere un análisis del flujo de datos pero no de las decisiones, por lo que el analista de
sistemas escribió “analizar el flujo de datos” como el paso individual en la fase media. Por último se descom-
pone la preparación de la propuesta en tres pasos: realizar un análisis de costo-beneficio, preparar la propuesta
y presentarla.
Desde luego que el analista de sistemas tiene la opción de descomponer los pasos incluso aún más. Por
ejemplo, podría especificar cada una de las personas a entrevistar. El grado de detalle necesario depende del pro-
yecto, pero todos los pasos críticos deben aparecer en los planes.
Algunas veces la parte más difícil de la planeación de un proyecto es el paso crucial de estimar el tiempo
requerido para completar cada tarea o actividad. Cuando se les preguntó sobre los motivos de retrasarse en un
proyecto específico, los miembros del equipo del proyecto hablaron sobre las malas estimaciones en la progra-
mación de los tiempos que obstaculizaron el éxito del proceso desde su inicio. No hay sustituto para la experien-
cia al estimar los requerimientos de tiempo; los analistas de sistemas que han tenido la oportunidad de aprender
sobre ello son afortunados.
Los planificadores han intentado reducir la incertidumbre inherente al determinar las estimaciones de
tiempo mediante una proyección de las estimaciones más probables, pesimistas y optimistas, para después
utilizar una fórmula de promedio ponderado con el fin de determinar el tiempo esperado que una actividad
requerirá. Sin embargo, esta metodología apenas si ofrece algo más de confianza. Tal vez la mejor estrategia
para el analista de sistemas sea adherirse a una metodología estructurada para identificar las actividades y
describirlas con el suficiente detalle. De esta forma, el analista de sistemas podrá por lo menos limitar las sor-
presas desagradables.
Uso de gráficos de Gantt para programar proyectos
Un gráfico de Gantt es una forma fácil de programar tareas. Es un gráfico en el que las barras representan cada
tarea o actividad. La longitud de cada barra representa la longitud relativa de la tarea.
En la figura 3.18 hay un ejemplo de un gráfico de Gantt bidimensional, en el cual el tiempo se indica en la
dimensión horizontal y una descripción de las actividades conforma la dimensión vertical. En este ejemplo, el
gráfico de Gantt muestra la fase de análisis o recopilación de información del proyecto. En este gráfico podemos
observar que, por ejemplo, las entrevistas requerirán tres semanas y la administración del cuestionario requerirá
cuatro. Estas actividades se traslapan la mayor parte del tiempo. En el gráfico, el símbolo especial indica que
es la semana 9. Las barras con sombras de colores representan proyectos o partes de proyectos que se han com-
pletado, lo cual nos indica que el analista de sistemas está atrasado en la introducción de los prototipos pero ade-
lantado en el análisis de los flujos de datos. Hay que tomar acción en cuanto a introducir los prototipos pronto,
de manera que no se retrasen las demás actividades o incluso el proyecto en sí como resultado.
La principal ventaja del gráfico de Gantt es su simpleza. El analista de sistemas no sólo descubrirá que esta
técnica es fácil de usar, sino que también se presta para una comunicación valiosa con los usuarios finales. Otra
ventaja de usar un gráfico de Gantt es que las barras que representan actividades o tareas se dibujan a escala; es
decir, el tamaño de la barra indica la longitud de tiempo relativa que se requerirá para completar cada tarea.
Actividad
Actividad incompleta
Actividad completada
Actividad parcialmente
completada
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Realizar entrevistas
Administrar cuestionarios
Leer informes de la compañía
Analizar flujos de datos
Introducir prototipo
Observar reacciones
Realizar análisis de costo-beneficio
Preparar la propuesta
Presentar la propuesta
Semanas
Semana actual
FIGURA 3.18
Uso de un gráfico de Gantt
bidimensional para planear
actividades que se pueden realizar
en paralelo.www.xlibros.com

80 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Uso de diagramas PERT
PERT es un acrónimo que significa Técnicas de evaluación y revisión de programas. Un programa (sinónimo de
proyecto) se representa mediante una red de nodos y flechas que después se evalúan para determinar las activida-
des críticas, mejorar el programa de trabajo en caso de ser necesario y revisar el avance una vez que se empiece
el proyecto. PERT se desarrolló a finales de la década de 1950 para usarlo en el proyecto del submarino nuclear
Polaris de la Marina de los EE.UU. Según se informa, ahorró a la Marina de los EE.UU. dos años de tiempo de
desarrollo.
PERT es útil cuando las actividades se pueden realizar en paralelo en vez de hacerlo en secuencia. El ana-
lista de sistemas se puede beneficiar de PERT al aplicarlo en los proyectos de sistemas a una escala menor, en
especial cuando algunos miembros del equipo pueden trabajar en ciertas actividades al mismo tiempo que otros
compañeros trabajan en otras.
En la figura 3.19 se compara un gráfico de Gantt simple con un diagrama PERT. Las actividades que se
expresan en el gráfico de Gantt como barras se representan mediante flechas en el diagrama PERT. La longitud
de las flechas no tiene relación directa con la duración de las actividades. Los círculos en el diagrama PERT se
denominan eventos y se pueden identificar mediante números, letras o cualquier otro método arbitrario de desig-
nación. Los nodos circulares sirven para 1) reconocer que una actividad se completó y 2) indicar qué actividades
hay que completar para poder empezar una nueva (precedencia).
En realidad, la actividad C no se puede empezar sino hasta que se termine la actividad A. La precedencia no
se indica de ninguna forma en el gráfico de Gantt, por lo que no es posible saber si la actividad C está progra-
mada para empezar el día 4 a propósito o por coincidencia.
Un proyecto tiene un inicio, una parte media y un final; el inicio es el evento 10 y el final es el evento 50.
Para encontrar la longitud del proyecto se identifica cada una de las rutas de principio a fin y se calcula la longi-
tud de cada ruta. En este ejemplo, la ruta 10-20-40-50 tiene una longitud de 15 días, mientras que la ruta 10-30-
40-50 tiene una longitud de 11 días. Incluso cuando una persona puede estar trabajando en la ruta 10-20-40-50 y
otra en la ruta 10-30-40-50, el proyecto no es una carrera, sino que requiere que se completen ambos conjuntos
de actividades (o rutas); en consecuencia, el proyecto tardará 15 días en completarse.
La ruta más larga se conoce como la ruta crítica. Aunque ésta se determina mediante el cálculo de la ruta
más larga, se define como la ruta que provocará que todo el proyecto se atrase si se encuentra en ella un retraso
de incluso un día. Tenga en cuenta que si está retrasado por un día en la ruta 10-20-40-50, todo el proyecto tardará
más tiempo, pero si está retrasado por un día en la ruta 10-30-40-50 no todo el proyecto sufrirá. A la libertad de
retrasarse un poco en las rutas no críticas se le denomina tiempo de inactividad.
En ocasiones los diagramas PERT necesitan seudoactividades, conocidas como actividades simuladas, para
preservar la lógica del diagrama o aclararlo. En la figura 3.20 aparecen dos diagramas PERT con actividades
simuladas. Los proyectos 1 y 2 son bastante distintos y la forma en que se dibuja la actividad simulada ayuda
a aclarar la diferencia. En el proyecto 1 la actividad C se puede iniciar sólo si se terminaron las actividades A y B,
A
B
C
D
E
2 4 6 8 10 12 14 16
A, 4 C, 5
B, 2 D, 3
E, 6
10
20
30
40 50
FIGURA 3.19
Comparación entre los gráficos de
Gantt y los diagramas PERT para
programar actividades.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 81
ya que todas las flechas que entran a un nodo deben completarse antes de salir del nodo. Sin embargo, en el pro-
yecto 2 la actividad C sólo requiere que se complete la actividad B y, por lo tanto, puede empezar mientras la
actividad A se esté llevando a cabo.
El proyecto 1 tarda 14 días en completarse, mientras que el proyecto 2 requiere sólo 9 días. Sin duda, la ac-
tividad simulada en el proyecto 1 es necesaria, ya que indica una relación de precedencia crucial. Por otra parte,
la actividad simulada en el proyecto 2 no se requiere, por lo que la actividad A se podría dibujar del nodo 10 al
nodo 40 para eliminar por completo el evento 20.
Existen muchas razones para utilizar un diagrama PERT en vez de un gráfico de Gantt. El diagrama PERT
permite:
1. Identificar con facilidad el orden de precedencia.
2. Identificar con facilidad la ruta crítica y, en consecuencia, las actividades críticas.
3. Determinar con facilidad el tiempo de inactividad.
UN EJEMPLO DE PERT Suponga que un analista de sistemas trata de establecer un programa de horarios realista
para las fases de recopilación de datos y propuesta del ciclo de vida del análisis y diseño de sistemas. El analista
de sistemas analiza la situación y hace una lista de las actividades que hay que realizar a lo largo del camino.
Esta lista, que se muestra en la figura 3.21, también muestra que algunas actividades deben realizarse antes que
otras. Las estimaciones de tiempo se determinaron según lo descrito en una sección anterior de este capítulo.
DIBUJAR EL DIAGRAMA PERT Para construir el diagrama PERT, el analista primero se basa en las actividades
que no requieren actividades predecesoras; en este caso A (realizar entrevistas) y C (leer los informes de la
compañía). En el ejemplo de la figura 3.22, el analista optó por enumerar los nodos como 10, 20, 30 y así en lo
sucesivo, y dibujó dos flechas saliendo del nodo inicial 10. Estas flechas representan las actividades A y C, y
se identifican como tales. Los nodos enumerados como 20 y 30 se dibujan al final de estas respectivas flechas.
A, 9
B, 2 C, 5
C, 5
A, 9
B, 2
20
10 40
10 40
30
20
30
Actividad
simulada
Actividad
simulada Proyecto 1
Proyecto 2
FIGURA 3.20
La precedencia de las actividades
es importante para determinar la
longitud del proyecto al utilizar un
diagrama PERT.
Actividad DuraciónPredecesor
A
B
C
D
E
F
G
H
I
Realizar entrevistas
Administrar cuestionarios
Leer informes de la compañía
Analizar el flujo de datos
Introducir el prototipo
Observar las reacciones al prototipo
Realizar un análisis de costo-beneficio
Preparar la propuesta
Presentar la propuesta
Ninguno
A
Ninguno
B, C
B, C
E
D
F, G
H
3
4
4
8
5
3
3
2
2
FIGURA 3.21
Listado de las actividades que
se utilizará en el dibujo de un
diagrama PERT.www.xlibros.com

82 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
A, 3
C, 4
B, 4
D, 8
E, 5 F, 3
G, 3 H, 2 I, 2
30 50
40
60 70 8010
20
FIGURA 3.22
Un diagrama PERT completo para
la fase de análisis de un proyecto
de sistemas.
El siguiente paso es buscar una actividad que sólo requiera a A como predecesor; la tarea B (administrar
cuestionarios) es la única, por lo que se puede representar mediante una flecha dibujada desde el nodo 20
hasta el nodo 30.
Como las actividades D (analizar el flujo de datos) y E (introducir el prototipo) requieren que las ac-
tividades B y C se completen para poder empezar, las flechas etiquetadas como D y E se dibujan desde el
nodo 30, el evento que reconoce que se completaron las actividades B y C. Este proceso continúa hasta que
se completa todo el diagrama PERT. Observe que el proyecto completo termina en un evento identificado
como el nodo 80.
IDENTIFICAR LA RUTA CRÍTICA Una vez dibujado el diagrama PERT, para identificar la ruta crítica se calcula
la suma de los tiempos de las actividades en cada ruta y se elige la ruta más larga. En este ejemplo hay cuatro
rutas: 10-20-30-50-60-70-80, 10-20-30-40-60-70-80, 10-30-50-60-70-80 y 10-30-40-60-70-80. La ruta más larga
es 10-20-30-50-60-70-80, que tarda 22 días. Es esencial que el analista de sistemas supervise con cuidado las
actividades en la ruta crítica para poder mantener el proyecto completo a tiempo o incluso reducir la longitud del
proyecto, si se puede garantizar.
ADMINISTRACIÓN DEL PROYECTO
El proceso de análisis y diseño puede ser difícil de manejar, en especial cuando el sistema a desarrollar es grande.
Para mantener las actividades de desarrollo lo más manejables que sea posible, por lo general empleamos algu-
nas de las técnicas de la administración de proyectos para ayudarnos a organizar todo.
Un aspecto importante de la administración de proyectos es cómo manejar nuestro programa de horarios
para terminar el sistema a tiempo, pero no es lo único que se requiere. La persona a cargo, el gerente del pro-
yecto, es a menudo el jefe de analistas de sistemas. El gerente del proyecto necesita comprender cómo deter-
minar qué es necesario y cómo iniciar un proyecto; cómo desarrollar la definición de un problema, examinar
la viabilidad de completar el proyecto de sistemas, reducir el riesgo, identificar y administrar las actividades, y
contratar, administrar y motivar a los demás miembros del equipo.
Cómo lidiar con la complejidad del sistema
Los modelos de estimaciones, como Constar (www.softstarsystems.com) o Construx (www.construx.com),
trabajan de la siguiente forma: primero el analista de sistemas introduce una estimación del tamaño del sis-
tema. Ésta se puede introducir de distintas formas, incluyendo las líneas de código fuente del sistema actual.
Después puede ser útil ajustar el grado de dificultad con base en qué tan familiarizado esté el analista con este
tipo de proyecto.
También se consideran otras variables, como la experiencia o capacidad del equipo, el tipo de plataforma o
sistema operativo, el nivel de capacidad de uso del software terminado (por ejemplo, cuáles lenguajes son nece-
sarios) y otros factores que pueden impulsar los costos. Una vez introducidos los datos se realizan los cálculos y
se produce una proyección aproximada de la fecha de terminación. A medida que el proyecto se lleva a cabo, es
posible obtener estimaciones más específicas.
Otra forma de estimar la cantidad de trabajo a realizar y el personal necesario para completar un proyecto se
conoce como análisis de puntos de función. Este método toma los cinco componentes principales de un sistema
computacional —1) entradas externas, 2) salidas externas, 3) consultas externas, 4) archivos lógicos internos y
5) archivos de interfaz externos— y después los califica en términos de complejidad.
El análisis de puntos de función puede estimar el tiempo requerido para desarrollar un sistema en distintos
lenguajes computacionales y compararlos entre sí. Para obtener más información sobre el análisis de puntos de
función, visite el sitio Web del Grupo de usuarios internacionales de puntos de función en www.ifpug.org.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 83
ADMINISTRACIÓN DE LAS ACTIVIDADES DE ANÁLISIS Y DISEÑO
Además de administrar el tiempo y los recursos, los analistas de sistemas también deben administrar a las perso-
nas. Esto requiere una comunicación precisa con los miembros del equipo que hayan sido seleccionados con base
en su competencia y compatibilidad. Es necesario establecer los objetivos para la productividad del proyecto y
hay que motivar a los miembros de los equipos de análisis de sistemas para lograrlos.
Ensamblar un equipo
Es conveniente ensamblar un equipo. Si el gerente del proyecto tiene la oportunidad de crear el equipo ideal
compuesto por personas experimentadas para desarrollar un sistema, ¿a quién debería escoger? En general, los
gerentes de proyectos necesitan buscar a otros que compartan sus valores de trabajo en equipo guiados por el
deseo de producir un sistema de alta calidad a tiempo y dentro del presupuesto. Otras características deseables
incluyen una buena ética laboral, honestidad, competencia, la disposición de asumir el liderazgo con base en la
experiencia, la motivación, el entusiasmo por el proyecto y la confianza de sus compañeros de equipo.
El gerente del proyecto necesita conocer los principios de negocios, pero no está de más contar con alguna
otra persona en el equipo que comprenda la forma en que opera una empresa. Tal vez esta persona debería ser
un especialista en la misma área que la del sistema que se va a desarrollar. Al desarrollar un sitio de comercio
electrónico, los equipos pueden conseguir la ayuda de alguien en marketing; los que desarrollen un sistema de
inventarios pueden preguntar a una persona con experiencia en producción y operaciones para que comparta su
experiencia.
Lo ideal sería que un equipo tuviera dos analistas de sistemas. De esta forma se pueden ayudar entre sí, re-
visar uno el trabajo del otro y equilibrar sus cargas de trabajo según se requiera. Sin duda existe la necesidad de
A T R A C T I V O D E L A M A C
La codificación de colores ayuda a un gerente de proyectos a poner en orden las fases, tareas y recursos similares.
OmniPlan, disponible para la Mac, aprovecha la codificación de colores para establecer un proyecto, identificar las
tareas, identificar la ruta crítica y marcar las situaciones imposibles.
FIGURA 3.MAC
El software de administración de proyectos OmniPlan de The Omni Group.www.xlibros.com

84 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
tener en el equipo personas con habilidades de programación. La codificación es importante, pero las personas
que sepan cómo realizar recorridos, revisiones, pruebas y documentar sistemas son también importantes. Algu-
nas personas son buenas para ver la idea general mientras que otras tienen un buen desempeño cuando las tareas
se descomponen en otras más pequeñas. Cada equipo debe tener ambos tipos de individuos.
Además de lo básico, un gerente de proyectos debe buscar personas con experiencia y entusiasmo. La expe-
riencia es en especial importante cuando tratamos de estimar el tiempo requerido para completar un proyecto. La
experiencia en programación puede referirse a que el código se podría desarrollar cinco veces más rápido que si
lo desarrollara un equipo inexperto. También es útil contar con un experto de capacidad de uso en el equipo.
El equipo debe estar motivado. Una forma de mantener la orientación positiva del mismo durante todo el
proceso es seleccionar a las personas adecuadas desde el inicio. Busque entusiasmo, imaginación y la habilidad
de comunicarse con distintos tipos de personas. Estos atributos básicos contienen el potencial para el éxito. Tam-
bién es conveniente contratar buenos redactores y oradores elocuentes que puedan presentar propuestas y traba-
jar directamente con los clientes.
La confianza es una parte importante de un equipo. Todos los miembros del proyecto deben actuar respon-
sablemente y comprometer su mejor esfuerzo para completar su parte del proyecto. Tal vez las personas tengan
estilos de trabajo distintos, pero todos necesitan estar de acuerdo en trabajar en conjunto hacia la obtención de
una meta común.
Estrategias de comunicación para administrar equipos
Cada equipo tiene una personalidad particular resultante de combinar a los miembros entre sí de una manera
que se genera una red totalmente nueva de interacciones. Una forma de organizar lo que usted piensa sobre los
equipos es visualizarlos como si estuvieran siempre buscando un equilibrio entre realizar el trabajo a la mano y
mantener las relaciones entre los miembros del equipo.
De hecho, es común que los equipos tengan dos líderes y no solo uno. Por lo general surge una persona que
dirige a los miembros para realizar tareas y otra que se preocupa por las relaciones sociales entre los miembros
E X P E R I E N C I A D E H Y P E R C A S E ® 3 . 1
“Espero que todos con los que se haya encontrado en MRE lo
hayan tratado bien. He aquí un breve repaso de algunas de las
formas en las que puede acceder a nuestra organización a través de
HyperCase. El área de recepción en MRE contiene los vínculos
clave para el resto de nuestra organización. Tal vez ya descubrió
estos vínculos por su cuenta, pero quisiera recordarle sobre ellos
en este momento, ya que no me gustaría absorberme tanto en el
resto de los problemas de la organización como para olvidar men-
cionarlos”.
“La entrada vacía que puede ver es un vínculo a la siguiente
sala, a la cual llamamos Atrio Este (East Atrium). Tal vez haya ob-
servado que todas las entradas abiertas son vínculos a salas adya-
centes. Observe el mapa del edificio que se muestra en el área de
recepción. Puede ir a las áreas públicas como la cantina, pero como
sabe, puede acceder a una oficina privada sólo si lo acompaña un
empleado. No puede entrar ahí por su cuenta”.
“Para estos momentos tal vez haya observado los dos docu-
mentos y la computadora en la pequeña mesa en el área de recep-
ción. El documento pequeño es el directorio telefónico interno de
MRE. Sólo necesita hacer clic en el nombre de un empleado y, si la
persona se encuentra en la empresa, le concederá una entrevista y
un paseo por la oficina. Dejaré a su criterio averiguar qué es el otro
documento”.
“La computadora en la mesa está encendida y muestra la pá-
gina Web inicial de MRE. Debería dar un vistazo al sitio corpora-
tivo y visitar todos los vínculos. Este sitio cuenta la historia de
nuestra empresa y las personas que trabajan aquí. Estamos muy
orgullosos de él y hemos recibido retroalimentación positiva de
nuestros visitantes”.
“Si ya tuvo oportunidad de entrevistar a unas cuantas personas
y ver cómo funciona nuestra empresa, no hay duda de que ha em-
pezado a darse cuenta de algunas de las políticas involucradas.
Aunque también estamos preocupados por más cuestiones técnicas;
por ejemplo, qué es lo que constituye la viabilidad para un proyecto
de capacitación y qué es lo que no”.
Preguntas de HYPERCASE
1. ¿Qué criterio utiliza la Unidad de capacitación (Training
Unit) para juzgar la viabilidad de un nuevo proyecto? Haga
una lista.
2. Haga una lista de los cambios o modificaciones a estos
criterios que usted recomendaría.
3. Snowden Evans le pidió que ayudara a preparar una
propuesta para un nuevo sistema de seguimiento de
proyectos para la Unidad de capacitación. Describa
brevemente la viabilidad técnica, económica y operacional
de cada alternativa para un sistema de rastreo de proyectos
propuesto para la Unidad de capacitación.
4. ¿Qué opción recomendaría? Use evidencia de HyperCase
para respaldar su decisión.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 85
del grupo. Ambos son necesarios para el equipo. Otros investigadores han etiquetado a estos individuos respec-
tivamente como líder de tareas y líder socioemocional. Cada equipo está sujeto a tensiones que surgen del hecho
de buscar un equilibrio entre realizar las tareas y mantener las relaciones entre los miembros del equipo.
Para que el equipo pueda preservar su efectividad hay que resolver las tensiones en forma continua. Si sólo
minimizamos o ignoramos las tensiones, el equipo se volverá inefectivo y al final se desintegrará. Gran parte de
la liberación necesaria de la tensión se puede lograr a través del uso habilidoso de la retroalimentación por parte
de todos los miembros del equipo. Sin embargo, todos los miembros tienen que estar de acuerdo en que la
forma de interactuar (es decir, el proceso) es lo suficientemente importante como para merecer algo de tiempo.
En una sección posterior veremos los objetivos de productividad para los procesos.
Para asegurar que todos estén de acuerdo en la interacción apropiada de los miembros, hay que crear nor-
mas de equipo explícitas e implícitas (expectativas, valores y formas de comportamiento colectivas) para guiar
a los miembros en sus relaciones. Las normas de un equipo le pertenecen a éste y no necesariamente se pueden
transferir a otro. Estas normas cambian a través del tiempo y se pueden considerar más como un proceso de in-
teracción que un producto.
Las normas pueden ser funcionales o disfuncionales. Sólo porque un comportamiento específico sea una
norma para un equipo no significa que esté ayudándolo a lograr sus objetivos. Por ejemplo, la expectativa de que
los miembros más recientes tengan que realizar toda la programación de tiempos de los proyectos puede ser una
norma de equipo. Al adherirse a ésta, el equipo está colocando mucha presión en los nuevos miembros y no está
aprovechando por completo la experiencia del mismo. Es una norma que, si se lleva a cabo, podría hacer que los
miembros del equipo desperdicien recursos valiosos.
Los miembros del equipo necesitan explicitar las normas y evaluar en forma periódica si son funcionales o
disfuncionales para ayudar a que el equipo logre sus objetivos. La expectativa primordial para su equipo debe ser
que el cambio es la norma. Pregúntese si las normas del equipo ayudan o dificultan el progreso del equipo.
Establecer objetivos de productividad del proyecto
Cuando haya trabajado con los miembros del equipo en varios tipos de proyectos, usted o el líder de su equipo
adquirirán perspicacia para proyectar lo que el equipo puede lograr en un periodo específico de tiempo. Si utiliza
las sugerencias descritas en la sección anterior de este capítulo sobre los métodos para estimar el tiempo reque-
rido y las acopla con la experiencia, el equipo podrá establecer objetivos de productividad que valgan la pena.
O P O R T U N I D A D D E C O N S U L T O R Í A 3 . 5
Cuidar los objetivos
“ Esto es lo que creo podemos lograr en las siguientes cinco
semanas”, dice Hy, el líder de su equipo de análisis de sistemas,
sacando con mucha seguridad un programa donde relaciona una
lista de los miembros del equipo con una de objetivos a corto plazo.
Hace apenas una semana su equipo de análisis de sistemas pasó por
una intensa reunión para agilizar el programa de su proyecto para
Kitchenet, Ontario, Redwings, una organización de hockey.
Los otros tres miembros del equipo miran sorprendidos la ta-
bla. Finalmente uno de los miembros, Rip, habla: “Estoy en shock.
De por sí cada uno de nosotros tiene mucho por hacer, y ahora
esto”.
Hy contesta en forma defensiva, “Tenemos que aspirar alto,
Rip. Están en pretemporada. Es el único momento en que podemos
conseguirlos. Si establecemos nuestros objetivos a un nivel dema-
siado bajo no terminaremos el prototipo del sistema, y mucho me-
nos el sistema en sí, antes de que pase otra temporada de hockey. La
idea es brindar a Kitchener Redwings la ventaja para pelear por
medio del uso de su nuevo sistema”.
Fiona, otro miembro del equipo, entra a la discusión diciendo:
“¡Dios sabe que sus jugadores no les pueden dar eso!” Se detiene a
esperar el acostumbrado refunfuñar del grupo reunido y después con-
tinúa: “Pero en serio, estos objetivos son asesinos. Por lo menos po-
drían haber pedido nuestra opinión, Hy. Incluso hasta podríamos tener
un mejor conocimiento que tú en cuanto a lo que es posible hacer”.
“Éste es un problema apremiante; no una fiesta de té, Fiona”,
le responde Hy. “Efectuar una delicada encuesta con los miembros
del equipo no era una de nuestras opciones. Había que hacer algo
rápido y me decidí por estos objetivos. Opino que enviemos nuestro
programa de horarios a la administración con base en ellos. Pode-
mos posponer las fechas de entrega más adelante si es necesario.
Pero de esta forma ellos sabrán que nos comprometimos a tratar de
lograr mucho durante la pretemporada”.
Como el cuarto miembro que escucha este continuo intercam-
bio de palabras, formule tres sugerencias que ayudarían a Hy a
mejorar su metodología para la formación y presentación de objeti-
vos. ¿Qué tan motivado cree usted que estará el equipo si comparten
la opinión de Fiona en cuanto a los objetivos de Hy? ¿Cuáles son
las posibles ramificaciones de plantear a la administración unos
objetivos demasiado optimistas? Escriba un párrafo dedicado a los
efectos a corto plazo y otro en el que discuta sobre los efectos a
largo plazo de establecer objetivos demasiado altos.www.xlibros.com

86 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Los analistas de sistemas están acostumbrados a pensar acerca de los objetivos de productividad para los
empleados que muestran salidas tangibles, como el número de pantalones de mezclilla que se cosen por hora, el
número de entradas introducidas por minuto o el número de artículos que se escanean por segundo. Sin embargo
y a medida que aumenta la productividad de la manufactura, es cada vez más claro que la productividad adminis-
trativa debe mantener el ritmo. Es con este propósito en mente que se establecen los objetivos de productividad
para el equipo de análisis de sistemas.
El equipo necesita formular los objetivos y estar de acuerdo en ellos; además se deben basar en la experien-
cia de los miembros del equipo, el desempeño en proyectos anteriores y la naturaleza del proyecto específico. Los
objetivos variarán un poco para cada proyecto que se emprenda, ya que algunas veces se instalará todo un sistema
mientras que otros proyectos podrían involucrar modificaciones limitadas a una parte de un sistema existente.
Motivación de los miembros del equipo del proyecto
Aunque la motivación es un tema en extremo complejo, es conveniente considerarlo en esta etapa, aunque sea por
un momento. Para simplificar de más hay que recordar que las personas se unen a las organizaciones para mantener
algunas de sus necesidades básicas, como alimentación, vestido y albergue. Sin embargo, todos los humanos tienen
también necesidades de mayor nivel, entre las cuales están la afiliación, el control, la independencia y la creativi-
dad. Las personas se motivan para satisfacer las necesidades que no se han cumplido en varios niveles.
Los miembros de un equipo se pueden motivar, al menos en forma parcial, por medio de la participación en
el establecimiento de los objetivos, como vimos en la sección anterior. El acto en sí de establecer un objetivo de-
safiante pero alcanzable y después comparar el rendimiento en forma periódica con el objetivo parece funcionar
a la hora de motivar a las personas. Los objetivos actúan casi como imanes para atraer a las personas al éxito.
Parte de la razón por la que el proceso de establecer objetivos motiva a las personas es que los miembros del
equipo saben con exactitud lo que se espera de ellos antes de cualquier revisión del desempeño. El éxito del es-
tablecimiento de objetivos para motivar a las personas también se puede atribuir a ello, con lo cual se concede a
cada uno de los miembros del equipo cierta autonomía para lograr los objetivos. Aunque un objetivo es predetermi-
nado, el medio para lograrlo tal vez no lo sea. En este caso los miembros del equipo tienen la libertad de utilizar
su propia experiencia y habilidad para cumplir sus objetivos.
El establecimiento de objetivos también puede motivar a los miembros del equipo debido a que les pone en
claro a ellos y a las demás personas involucradas qué se debe hacer para obtener resultados. Los miembros del
equipo también se motivan con base en los objetivos, ya que éstos definen el nivel de éxito que se espera de ellos.
Al utilizar los objetivos de esta forma se simplifica la atmósfera de trabajo, pero también se electrifica debido a la
incertidumbre con respecto a completar lo que se esperaba.
Administración de proyectos de comercio electrónico
Muchas de las metodologías y técnicas que vimos antes en este libro se pueden transferir a la administración
de proyectos de comercio electrónico. Sin embargo, le advertimos que a pesar de tantas similitudes, también
hay muchas diferencias. Una de ellas es que los datos que utilizan los sistemas de comercio electrónico están
esparcidos por toda la organización. Por lo tanto, no sólo termina administrando datos en un departamento auto-
contenido, o incluso en una unidad aislada. Por ende pueden entrar en juego muchas políticas de la organización,
ya que es común que las unidades quieran proteger los datos que generan y no comprendan la necesidad de com-
partirlos con toda la organización.
Otra diferencia contundente es que por lo general los proyectos de comercio electrónico necesitan más per-
sonal con distintas habilidades: desarrolladores, consultores, expertos en bases de datos e integradores de siste-
mas, de todas las áreas de la organización. Si lo definimos en forma concisa, los grupos de proyectos estables
que existan dentro de un grupo de ingeniería de sistemas (IS) o de un equipo de desarrollo de sistemas serán la
excepción a la regla. Además, como es probable que se requiera mucha ayuda al principio, los gerentes de pro-
yectos de comercio electrónico necesitan construir sociedades tanto externas como internas mucho antes de la
implementación del proyecto, y tal vez tengan que compartir talentos entre proyectos para sufragar los costos de
las implementaciones de comercio electrónico y reunir el número requerido de personas con la experiencia nece-
saria. El potencial que tienen las políticas organizacionales de separar a los miembros de un equipo es muy real.
Una manera de evitar que las políticas saboteen un proyecto es que el gerente del proyecto de comercio
electrónico enfatice la integración del comercio electrónico con los sistemas internos de la organización, dando
relevancia al aspecto organizacional del proyecto. Como un gerente de proyectos de comercio electrónico nos
dijo: “La parte sencilla de todo esto es diseñar la interfaz de usuario [lo que ve el consumidor]. El verdadero de-
safío está en integrar el comercio electrónico de una manera estratégica en todos los sistemas de la organización”.
La cuarta diferencia entre la administración de proyectos tradicionales y la administración de proyectos de
comercio electrónico es que, como el sistema se enlazará con el mundo exterior a través de Internet, la seguridad
es de primordial importancia. El proceso de desarrollar e implementar un plan de seguridad antes de implantar el
nuevo sistema constituye un proyecto por sí solo, por lo que debemos administrarlo como tal.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 87
Creación de los estatutos del proyecto
Una parte del proceso de planeación consiste acordar qué se va a hacer y en qué momento. Tanto los analistas que
son consultores externos como los que son miembros de la organización necesitan especificar qué entregarán y
cuándo lo harán. En este capítulo le explicaremos las formas de estimar la fecha de entrega para el sistema com-
pleto, además de cómo identificar los objetivos organizacionales y evaluar la viabilidad del sistema propuesto.
Los estatutos del proyecto son una narrativa escrita que aclara las siguientes cuestiones:
1. ¿Qué espera el usuario del proyecto (cuáles son los objetivos)? ¿Qué hará el sistema para satisfacer las
necesidades (lograr los objetivos)?
2. ¿Cuál es el alcance (o los límites) del proyecto? (¿Qué considera el usuario que esté más allá del alcance del
proyecto?)
3. ¿Qué métodos de análisis utilizará el analista para interactuar con los usuarios en el proceso de recopilar los
datos, desarrollar y probar el sistema?
4. ¿Quiénes son los participantes clave? ¿Cuánto tiempo están dispuestos los usuarios y se pueden
comprometer a participar?
5. ¿Cuáles son los entregables del proyecto? (¿Cuáles son los componentes nuevos o actualizados de software,
hardware, procedimientos y documentación que los usuarios esperan que estén disponibles para interactuar
con ellos al momento de terminar el proyecto?)
6. ¿Quién evaluará el sistema y cómo lo hará? ¿Cuáles son los pasos en el proceso de evaluación? ¿Cómo y a
quién se comunicarán los resultados?
7. ¿Cuál es el cronograma estimado del proyecto? ¿Con qué frecuencia informarán los analistas sobre los
avances del proyecto?
8. ¿Quién capacitará a los usuarios?
9. ¿Quién se encargará de dar mantenimiento al sistema?
Los estatutos del proyecto describen en un documento escrito los resultados esperados del proyecto de sis-
temas (entregables) y el periodo para la entrega. En esencia, este documento se convierte en un contrato entre
el analista en jefe (o gerente del proyecto), su equipo de análisis y los usuarios de la organización que solicitan el
nuevo sistema.
Cómo evitar fracasos en los proyectos
Por lo general las primeras discusiones que haya tenido usted con la administración y las demás personas que
solicitan un proyecto, junto con los estudios de viabilidad que realice, son la mejor defensa posible para evitar
tomar proyectos que tengan una alta probabilidad de fracasar. Su capacitación y experiencia mejorarán su ca-
pacidad para juzgar si un proyecto vale la pena, junto con las motivaciones que impulsan a otros a solicitar los
proyectos. Si usted forma parte de un equipo de análisis de sistemas dentro de una empresa, se debe mantener al
tanto del clima político de la organización, así como de las situaciones financieras y competitivas.
Sin embargo, es importante recalcar que los proyectos de sistemas pueden y llegan a tener problemas gra-
ves. Los proyectos que se desarrollan mediante el uso de métodos ágiles no son inmunes a dichos problemas.
Para poder ilustrar lo que puede salir mal en un proyecto, es conveniente que el analista de sistemas dibuje un
diagrama de esqueleto de pescado o “fishbone” (también conocido como diagrama de causa y efecto, o diagrama
de Ishikawa). Si examina la figura 3.23 podrá ver que, en efecto, se asemeja al esqueleto de un pescado.
El valor de estos diagramas reside en que muestran una lista sistemática de todos los posibles problemas. En
el caso de la metodología ágil, es conveniente organizar el diagrama con base en una lista de todas las variables
de control de recursos en la parte superior y todas las actividades en la parte inferior. Algunos problemas como
el desplazamiento del programa de horarios podrían ser obvios, pero otros como la corrupción del alcance, o
“scope creep” (el deseo de agregar características después de que el analista escucha nuevas historias), o desarro-
llar características con poco valor, no lo son tanto.
También puede aprender de la sabiduría que obtuvieron las personas involucradas en fracasos de proyectos
anteriores. Cuando se les pidió que reflexionaran sobre la causa que provocó que fracasaran los proyectos, los
programadores profesionales alegaron que la administración había establecido fechas imposibles o poco realistas
para completar el proyecto, con base en el mito de que con sólo agregar más personas a un proyecto se agilizaría
su desarrollo (incluso cuando la fecha de entrega original del proyecto era poco realista), y que la administración
se comportó de una manera irracional al prohibir que el equipo buscara expertos profesionales fuera del grupo
para ayudarlos a resolver problemas específicos.
Recuerde que no está solo al decidir si empieza o no un proyecto. Aunque la administración esté al tanto de las
recomendaciones de su equipo, serán ellos quienes decidan en última instancia si vale la pena continuar con el estu-
dio de un proyecto propuesto (es decir, si se van a invertir más recursos o no). El proceso de decisión de su equipo
debe ser abierto y capaz de resistir al escrutinio de los que estén fuera de él. Los miembros del equipo deben tener
en cuenta que no pueden separar su reputación y postura dentro de la organización de los proyectos que acepten.www.xlibros.com

88 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
LA PROPUESTA DE SISTEMAS
Organización de la propuesta de sistemas
Aunque el propósito de los estatutos del proyecto es identificar los objetos, determinar el alcance y asignar res-
ponsabilidades, el analista también necesita preparar una propuesta de sistemas en la que se incluya la mayor
cantidad de detalles sobre las necesidades, opciones y recomendaciones del sistema. En esta sección veremos el
contenido y el estilo que se utilizan para formular una propuesta de sistemas.
QUÉ DEBEMOS INCLUIR EN LA PROPUESTA DE SISTEMAS Hay diez secciones principales que conforman una
propuesta de sistemas por escrito. Cada una de estas partes tiene una función específica, por lo que en última
instancia la propuesta se debe ordenar de la siguiente manera:
1. Carta de presentación.
2. Portada del proyecto.
3. Índice de contenido.
4. Resumen ejecutivo (incluyendo las recomendaciones).
5. Esquema del estudio de sistemas con la documentación apropiada.
6. Resultados detallados del estudio de sistemas.
7. Alternativas de sistemas (tres o cuatro posibles soluciones).
8. Recomendaciones de los analistas de sistemas.
9. Resumen de la propuesta.
10. Apéndices (documentación variada, resumen de fases, correspondencia, etcétera).
En la propuesta de sistemas debemos incluir una carta de presentación para los gerentes y la fuerza de tra-
bajo de TI. Esta carta debe enlistar a las personas que hicieron el estudio e incluir un resumen de los objetivos
del mismo. La carta de presentación debe ser concisa y amigable.
En la portada debe incluir el nombre del proyecto, los nombres de los miembros del equipo de análisis de
sistemas y la fecha en que se envía la propuesta. El título de la misma debe expresar con precisión su contenido,
aunque también puede incluir algo de imaginación. El índice de contenido puede ser útil para los que leen pro-
puestas extensas. Si la propuesta tiene menos de 10 páginas puede omitir el índice de contenido.
Tasa de defectos excesiva
El cliente no está
satisfecho con la interfaz
Miedo al cambio
El diseño no es lo
bastante creativo
Tiempo
Alta rotación del personal
Características con
poco valor
Se requieren más
programadores
Corrupción del alcance
(scope creep)
Desplazamientos en el
programa de horarios
Hay que cambiar el código
debido a cambios en la
empresa
Retroalimentación
inadecuada de las
pruebas
Interrupción de las
comunicaciones
El sistema fracasa en
las pruebas
Comprensión incorrecta
de los negocios
Código demasiado
complejo
Costo AlcanceCalidad
Diseño Prueba Codificación Escucha
FIGURA 3.23
Podemos utilizar un diagrama de esqueleto de
pescado (fishbone) para identificar todo lo que
puede salir mal en el desarrollo de un sistema.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 89
El resumen ejecutivo puede tener de 250 a 375 palabras. En él se informa el quién, qué, cuándo, dónde, por
qué y cómo de la propuesta, de igual forma que lo haría el primer párrafo en un artículo de noticias. También
debe incluir las recomendaciones del analista de sistemas y la acción deseada por parte de la administración, ya
que algunas personas tendrán tiempo de leer sólo el resumen. Debe escribirse al último, después de completar el
resto de la propuesta.
El esquema del estudio de sistemas provee información sobre los métodos que se utilizaron en el estudio, y
quién o qué fue lo que se estudió. En esta sección se deben incluir los cuestionarios, las entrevistas, las muestras
de datos de archivo, los procesos de observación o creación de prototipos que se hayan utilizado en el estudio de
sistemas.
La sección de resultados detallados describe lo que descubrió el analista de sistemas en relación con las ne-
cesidades humanas y de sistemas por medio de todos los métodos descritos en la sección anterior. Aquí debemos
incluir las conclusiones sobre los problemas que experimentan los trabajadores al interactuar con tecnologías y
sistemas que pasan a primer plano a través del estudio. También hay que incluir los problemas o sugerir las opor-
tunidades que presentan las alternativas que presentaremos en la siguiente sección.
En la sección de la propuesta acerca de las alternativas de sistemas, el analista debe presentar dos o tres so-
luciones alternativas que hagan frente de manera directa a los problemas antes mencionados. Las alternativas que
se presenten aquí deben incluir una en la que se recomiende dejar el sistema como está. Hay que explorar cada
alternativa por separado. Además hay que describir los costos y beneficios de cada situación. Como por lo gene-
ral hay puntos de conflicto involucrados en cualquier solución, asegúrese de incluir las ventajas y desventajas de
cada una.
Cada alternativa debe indicar con claridad lo que deben hacer los usuarios y gerentes para implementarla. La
redacción debe ser lo más clara posible, como “Comprar computadoras portátiles para todos los gerentes de nivel
medio”, “Comprar software empaquetado para respaldar a los usuarios en el manejo del inventario” o “Modificar
el sistema existente mediante el financiamiento de esfuerzos internos de programación”.
Una vez que el analista de sistemas haya sopesado las alternativas, tendrá una opinión profesional definida so-
bre la solución que sea más funcional. La sección de recomendaciones del analista de sistemas expresa la solución
recomendada. Aquí hay que incluir las razones que respaldan la recomendación del equipo, para que sea fácil com-
prender por qué se recomienda. Esta recomendación debe fluir en forma lógica del análisis previo de las soluciones
alternativas; además debe relacionar claramente los hallazgos sobre la interacción humano-computadora con la op-
ción que se ofrece.
El resumen de la propuesta es un enunciado corto que refleja el contenido del resumen ejecutivo. En él se
informan los objetivos del estudio y la solución recomendada. El analista debe enfatizar una vez más la impor-
tancia y viabilidad del proyecto, junto con el valor de las recomendaciones para cumplir con los objetivos de los
usuarios y mejorar la empresa. Concluya la propuesta con una observación positiva.
El apéndice es la última parte de la propuesta de sistemas, y puede incluir cualquier información que el ana-
lista de sistemas considere de interés para ciertos individuos, pero que no sea esencial para comprender el estudio
de sistemas y lo que se está proponiendo.
Una vez que termine de escribir la propuesta de sistemas, seleccione cuidadosamente quiénes van a recibir
el informe. Entregue el informe personalmente a las personas que seleccionó. Su visibilidad es importante para la
aceptación y el éxito en última instancia del sistema.
Uso de figuras para una comunicación efectiva
Hasta este momento, el énfasis de esta sección ha estado en la audiencia de la propuesta de sistemas que usted
debe crear. Es importante utilizar tablas y gráficos, además del texto, para presentar los aspectos básicos del sis-
tema propuesto. Nunca hay que menospreciar un buen diseño.
La integración de figuras en su propuesta le ayuda a demostrar que usted está consciente de las distintas for-
mas en que las personas absorben la información. Las figuras en el informe complementan la información escrita
y siempre se deben interpretar con palabras; nunca deben ir solas.
USO EFECTIVO DE LAS TABLAS Aunque técnicamente las tablas no son ayudas visuales, son una manera distinta de
agrupar y presentar los datos analizados que el analista desea comunicar al lector de la propuesta.
Las tablas utilizan columnas y filas etiquetadas para presentar datos estadísticos o alfabéticos de una manera
organizada. Cada tabla se debe enumerar de acuerdo con el orden en el que aparezca en la propuesta y debe tener
un título representativo. En la figura 3.24 se muestran el esquema y la identificación apropiados para una tabla.
Algunos de los lineamientos para las tablas son:
1. Integre las tablas en el cuerpo de la propuesta. No las relegue a los apéndices.
2. Trate de ajustar toda la tabla verticalmente en una sola página, de ser posible.www.xlibros.com

90 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
3. Enumere y asigne un título a la tabla en la parte superior de la página. El título debe ser descriptivo y
representativo.
4. Etiquete cada fila y columna. Use más de una línea para un título, de ser necesario.
5. Use una tabla cuadriculada si hay espacio para ello. Las rayas verticales en las columnas mejoran la
legibilidad.
6. Use notas al pie si es necesario para explicar la información detallada contenida en la tabla.
En las secciones anteriores presentamos varios métodos para comparar costos y beneficios. Hay que poner los
resultados de esas comparaciones en tablas y mostrarlos así en la propuesta de sistemas. Si realiza un análisis
de punto de equilibro, debe incluir una tabla en la que se ilustren los resultados del análisis. La retribución
se puede mostrar en tablas que sirvan como apoyo adicional para los gráficos. También podría incluir en la pro-
puesta de sistemas una tabla pequeña en la que se comparen los sistemas computacionales o las opciones.
USO EFECTIVO DE LOS GRÁFICOS Hay muchos tipos de gráficos: de línea, de columna, de barras y de pastel, por
mencionar unos cuantos. Los gráficos de línea, de columna y de barra comparan variables, mientras que los de
barras y de áreas ilustran la composición del 100 por ciento de una entidad.
A continuación le mostramos los lineamientos para incluir gráficos efectivos en una propuesta (consulte la
figura 3.25):
1. Seleccione un estilo de gráfico que transmita de manera efectiva el significado que desea.
2. Integre el gráfico en el cuerpo de la propuesta.
3. Asigne al gráfico un número de figura secuencial y un título representativo.
4. Etiquete los ejes y las líneas, columnas, barras o piezas del pastel en el gráfico.
5. Incluya una clave para identificar y diferenciar las líneas de colores, las barras sombreadas o las áreas con
patrones cuadriculados.
Gran parte de los detalles que se incluyen en una propuesta de sistemas se obtienen de las entrevistas, los
cuestionarios, los muestreos, el descubrimiento de otros datos rigurosos y mediante la observación. En los si-
guientes dos capítulos hablaremos sobre estos temas.
Tipo de conjunto 2004 2005 2006 2007 2008 2009
40 kg, gris 3.5 3.4 3.7 3.0 2.5 2.0
48 kg, gris 5.9 5.5 5.1 4.6 2.0 2.0
55 kg, gris 3.9 4.8 5.5 3.5 4.2 5.5
68 kg, gris 1.0 1.9 2.2 2.5 1.3 1.2
100 kg, gris 1.2 1.8 1.5 0.7 1.2 1.5
55 kg, r,b,a* – – – 3.4 6.5 2.6
100 kg, r,b,a – – – 0.8 1.8 1.2
Tabla 4
Cantidad de conjuntos de mancuernas que se vendieron por peso
y color durante los años de 2004 a 2009, incluyéndolos
* r,b,a significa rojo, blanco y azul
Use notas al pie
para explicar la
información
Trate de ajustar la
tabla verticalmente
en una sola página.
Hay que etiquetar
las filas y columnas
Redacte un título
descriptivo. El uso
de un cuadro mejora
la apariencia de la
tabla.
FIGURA 3.24
Lineamientos para crear tablas
efectivas.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 91
Los cinco fundamentos más importantes de la administración
de proyectos que debe manejar el analista de sistemas son
1) inicio del proyecto: definición del problema, 2) determinar la
viabilidad del proyecto, 3) planeación y control de actividades,
4) programación de fechas y tiempos del proyecto y 5) admi-
nistración de los miembros del equipo de análisis de sistemas.
Al enfrentarse a las cuestiones sobre cómo pueden las empresas
cumplir con sus objetivos y resolver problemas de sistemas, el
analista crea una definición del problema. Esta definición es
un enunciado formal del problema, en el que se incluyen 1) las
cuestiones de la situación presente, 2) los objetivos para cada
cuestión, 3) los requerimientos que se deben incluir en todos
los sistemas propuestos y 4) las restricciones que limitan el
desarrollo de los sistemas.
Seleccionar un proyecto es una decisión difícil, ya que se
solicitarán más proyectos de los que realmente se puedan llevar
a cabo. Cinco criterios importantes de selección son 1) que el
proyecto solicitado esté respaldado por la administración,
2) que se sincronice en forma apropiada para comprometer los
recursos, 3) que ayude a que la empresa avance hacia la obten-
ción de sus objetivos, 4) que sea práctico y 5) que sea lo bas-
tante importante como para considerarlo por encima de otros
proyectos.
Si un proyecto solicitado cumple con estos criterios, se
puede realizar un estudio de viabilidad en cuanto a sus méritos
operacionales, técnicos y económicos. Por medio de este estu-
dio de viabilidad los analistas recopilan datos que permiten a la
administración decidir si se puede o no continuar con un estu-
dio de sistemas completo. Mediante un inventario ordenado del
equipo con el que ya se cuenta, los analistas de sistemas podrán
determinar con más efectividad si deben recomendar o no hard-
ware computacional nuevo, modificado o actual.
El hardware computacional se puede adquirir mediante
compra, arrendamiento o renta. Los distribuidores ofrecen
servicios de soporte como mantenimiento preventivo y capa-
citación para los usuarios, que por lo general se negocian por
separado. El software se puede crear como un producto perso-
nalizado, se puede comprar como un paquete de software co-
mercial de venta en canales convencionales (COTS) o se puede
subcontratar un proveedor de servicios de aplicación (ASP)
para que lo desarrolle.
Para preparar una propuesta de sistemas hay que identifi-
car todos los costos y beneficios de varias alternativas. El ana-
lista de sistemas cuenta con varios métodos a su disposición
para pronosticar a futuro los costos, beneficios, volúmenes de
transacciones y variables económicas que afectan a los costos
y beneficios. Éstos pueden ser tangibles (cuantificables) o in-
tangibles (no son cuantificables y es difícil compararlos direc-
tamente). Un analista de sistemas tiene muchos métodos a su
disposición para analizar costos y beneficios, entre los cuales
están el análisis de punto de equilibrio, el método de retribu-
ción y el análisis de flujo de efectivo.
Costo
($)
70,000
60,000
Punto de
equilibrio
50,000
40,000
30,000
20,000
10,000
2006 2007 2008 2009 2010
Año
Incluya una clave.
Incluya un
representativo
Costo del sistema
propuesto
Costo del sistema
actual
Figura 5
Se espera que el sistema propuesto
llegue al punto de equilibrio en 2010 Etiquete los ejes
FIGURA 3.25
Lineamientos para dibujar gráficos
de líneas efectivos.
RESUMENwww.xlibros.com

92 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
E X P E R I E N C I A D E H Y P E R C A S E ® 3 . 2
“Algunas veces, las personas que han estado aquí durante cierto
tiempo se sorprenden al ver cuánto hemos crecido. Admito que no
es fácil llevar la cuenta de lo que hace cada persona, o incluso de las
compras que ha realizado cada departamento en cuanto al hardware
y software. Pero estamos trabajando en eso. A Snowden le gustaría
ver más rendición de cuentas en las compras de computadoras.
Desea asegurarse de que sepamos lo que tenemos, en dónde y por
qué lo tenemos, quién lo usa y si está impulsando la productividad
de MRE o, dicho con sus propias palabras, ‘si sólo se trata de un
juguete costoso’ del cual podamos deshacernos”.
Preguntas de HYPERCASE
1. Complete un inventario de equipo de cómputo para la unidad
de capacitación y sistemas administrativos (Training and
Management Systems Unit) en el que describa todos los
sistemas que encuentre. Sugerencia: Cree un formulario de
inventario para simplificar su tarea.
2. Use los lineamientos de evaluación de software que vimos en
el libro para realizar una breve evaluación de GEMS, paquete
de software utilizado por los empleados de sistemas
administrativos (Management Systems). Elabore una breve
crítica de un párrafo de este software personalizado y
compárelo con el software comercial de venta en los canales
convencionales como Microsoft Project.
3. Enliste los costos y beneficios intangibles de GEMS, según
lo que informan los empleados de MRE.
4. Describa brevemente las dos alternativas que considera Snowden
para el sistema de rastreo e informes de proyectos propuesto.
5. ¿Qué factores organizacionales y políticos debe considerar
Snowden al proponer su nuevo sistema a MRE? (Describa
tres conflictos centrales en un párrafo corto.)
La planeación de un proyecto incluye la estimación del
tiempo requerido para cada una de las actividades del analista,
la programación de tiempos y fechas de estas actividades, y la
manera de agilizarlas en caso de ser necesario para asegurar
que el proyecto se termine a tiempo. Una técnica disponible
para que el analista de sistemas pueda programar tareas es el
gráfico de Gantt, el cual muestra las actividades como barras
en un gráfico.
Hay otra técnica conocida como Técnicas de evaluación
y revisión de programas (PERT), la cual muestra las activida-
des como flechas en una red. PERT ayuda al analista a determi-
nar la ruta crítica y el tiempo de inactividad, lo que constituye
la información requerida para el control efectivo del proyecto.
Se recomienda la creación de un documento en el que se
incluyan los estatutos del proyecto, el cual contiene las ex-
pectativas de los usuarios y los productos que el analista debe
FIGURA 3.HC1
La sala de recepción se asemeja a la de una empresa común. Busque el
directorio en esta pantalla de HyperCase si desea visitar a alguien.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 93
entregar, ya que los tiempos de entrega poco realistas exigidos
por la administración, el agregar personal innecesario a un pro-
yecto en el que se intenta cumplir con un tiempo de entrega
poco realista y el no permitir que los equipos de desarrollo
busquen ayuda de expertos fuera de su grupo inmediato, fueron
factores citados por los programadores como razones por las
que los proyectos fracasaban. Por lo general podemos evitar es-
tos fracasos si examinamos las motivaciones para los proyectos
solicitados, así como los motivos que tenga nuestro equipo para
recomendar o evitar un proyecto específico.
El analista de sistemas debe realizar tres pasos principales
para elaborar una propuesta efectiva de sistemas: organizar el
contenido de la propuesta en forma efectiva, escribir la pro-
puesta en un estilo de negocios apropiado y presentar en forma
oral una propuesta de sistemas informativa. Para que sea efec-
tiva, la propuesta se debe escribir en forma clara y compren-
sible; además hay que dividir su contenido en diez secciones
funcionales. Son importantes las consideraciones visuales a la
hora de elaborar una propuesta.
PALABRAS CLAVE Y FRASES
administración de proyectos de comercio electrónico
análisis de flujo de efectivo
análisis de punto de equilibrio
análisis de puntos de función
benchmarking
beneficios intangibles
beneficios tangibles
costos intangibles
costos tangibles
definición del problema
diagrama PERT
estatutos del proyecto
gráfico de Gantt
líder de tarea
líder socioemocional
media móvil
motivación del equipo
normas del equipo
objetivos de productividad
proceso de equipo
pronósticos
propuesta de sistemas
retribución
ruta crítica
soporte del distribuidor
valor presente
viabilidad económica
viabilidad operacional
viabilidad técnica
PREGUNTAS DE REPASO
1. ¿Cuáles son los cinco fundamentos principales de un proyecto?
2. Mencione tres formas de averiguar sobre los problemas o las oportunidades potencialmente asociados con una solución
de sistemas.
3. Enliste los cinco criterios para la selección de proyectos de sistemas.
4. Defina viabilidad técnica.
5. Defina viabilidad económica.
6. Defina viabilidad operacional.
7. Mencione cuatro criterios para evaluar el hardware de sistemas.
8. ¿Cuáles son las tres opciones principales para la adquisición de hardware computacional?
9. ¿Qué significa COTS?
10. ¿Qué implica un ASP, en términos de entrega de software?
11. Defina los costos y beneficios tangibles. Dé un ejemplo de cada uno.
12. Defina los costos y beneficios intangibles. Dé un ejemplo de cada uno.
13. Enliste cuatro técnicas para comparar los costos y beneficios de un sistema propuesto.
14. ¿Cuándo es útil el análisis de punto de equilibrio?
15. ¿Cuáles son las tres desventajas de usar el método de retribución?
16. ¿Cuándo se utiliza el análisis del flujo de efectivo?
17. Como lineamiento general, ¿cuándo se debe utilizar el análisis del valor presente?
18. ¿Qué es un gráfico de Gantt?
19. ¿Cuándo es útil un diagrama PERT para los proyectos de sistemas?
20. Mencione tres ventajas de usar un diagrama PERT en vez de un gráfico de Gantt para programar tiempos y fechas de los
proyectos de sistemas.
21. Defina el término ruta crítica.
22. ¿Cómo evalúa un gerente de proyectos el riesgo de que las cosas salgan mal y de tener eso en cuenta al planear el tiempo
requerido para completar el proyecto?
23. Mencione los dos tipos de líderes de equipo.
24. ¿Qué implica una norma de equipo disfuncional?
25. ¿Qué implica el proceso de equipo?
26. ¿Cuáles son tres razones por las que el establecimiento de objetivos parece motivar a los miembros del equipo de análisis
de sistemas?
27. ¿Cuáles son las cuatro formas en las que la administración de proyectos de comercio electrónico difiere de la
administración de proyectos tradicionales?www.xlibros.com

94 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
28. ¿Qué elementos contienen los estatutos del proyecto?
29. ¿Para qué se utiliza un diagrama de esqueleto de pescado (fishbone)?
30. ¿Cuáles son los tres pasos que debe seguir el analista de sistemas para elaborar una propuesta eficiente de sistemas?
31. Enliste las 10 secciones principales de la propuesta de sistemas.
PROBLEMAS
1. Williwonk’s Chocolates de St. Louis fabrica varios tipos de dulces y novedades de chocolate. La empresa tiene seis
tiendas en la ciudad: cinco en los principales aeropuertos metropolitanos y una pequeña sucursal de pedidos por correo.
Williwonk’s tiene un pequeño sistema de información computarizado que rastrea el inventario en su planta, ayuda a
programar la producción y algunas otras cosas más, pero este sistema no está enlazado directamente con ninguna de sus
tiendas de menudeo. El sistema de pedidos por correo se administra en forma manual.
Hace poco, varias tiendas de Williwonk’s experimentaron una erupción de quejas de los clientes de pedidos por
correo, debido a que los dulces llegaban echados a perder, que no llegaban cuando se les prometía o que nunca llegaban;
la empresa también recibió varias cartas en las que se quejaban de que los dulces en varios aeropuertos sabían rancios.
Williwonk’s ha estado vendiendo una nueva forma dietética de chocolate bajo en calorías, formulada con un edulcorante
artificial. Las ventas han sido activas, pero han surgido problemas por enviar el tipo incorrecto de chocolate a la
dirección en la que vive una persona diabética. Hubo varias quejas, por lo que Williwonk’s envió varias cajas gratis de
chocolate como desagravio.
A la gerencia le gustaría vender productos a través de Web, pero cuentan con sólo algunas páginas Web con
información sobre la compañía y un formulario de pedidos que se puede imprimir. No existen los pedidos a través de
Web. A uno de los ejecutivos principales le gustaría vender chocolates personalizados con el nombre de una persona en
cada pieza. Aunque el área de producción aseguró a la gerencia que esto se podría hacer fácilmente, no hay un método
para pedir tales chocolates personalizados.
Otro de los ejecutivos principales mencionó que Williwonk’s se asoció con varios fabricantes de chocolate
europeos y que importará chocolate de varios países. En la actualidad hay que hacer esto a través del teléfono, por
correo electrónico o por correo convencional. El ejecutivo desea un sitio Web interno que permita a los empleados
realizar pedidos directamente a las empresas asociadas. Todo esto ha provocado que varios gerentes soliciten un análisis
de tendencias. Cuando hay inventario en exceso algunos chocolates se arrancian, mientras que otras veces hay escasez de
ciertos tipos de chocolate.
Las tendencias de variación por temporadas y días festivos podrían ayudar a Williwonk’s a mantener un inventario
adecuado. El gerente de control de inventario insiste en que es necesario implementar todos los cambios antes de la
siguiente temporada festiva. “Hay que tener una fecha absoluta definida para que todo esté terminado”, recalcó Candy,
una de los gerentes de nivel superior. “Debemos asegurarnos de que todo esté trabajando perfectamente antes de que el
sitio se haga público”, continuó. “¡No quiero clientes que reciban los chocolates incorrectos!”. Además, el gerente de
procesamiento de pedidos mencionó que el sistema debe ser seguro.
Usted llevaba trabajando dos semanas con Williwonk’s en varias modificaciones para su sistema de información de
inventario cuando escuchó a dos gerentes discutir sobre estas cuestiones. Haga una lista de las posibles oportunidades o
problemas que se podrían convertir en proyectos de sistemas.
2. ¿De dónde proviene la mayor parte de la retroalimentación sobre los problemas con los productos de Williwonk’s en el
problema 1? ¿Qué tan confiables son las fuentes? Explique en un párrafo.
3. Después de conocerlos mejor, usted se acerca a los ejecutivos de la administración de Williwonk’s con sus ideas sobre
las posibles mejoras de sistemas que podrían hacerse cargo de algunos de los problemas o las oportunidades que se
mencionan en el problema 1.
a. Escriba en dos párrafos sus sugerencias para los proyectos de sistemas. Haga todas las suposiciones realistas que sea
necesario.
b. ¿Hay problemas u oportunidades descritas en el problema 1 que no sean adecuadas? Explique su respuesta.
4. Cree la definición de un problema para Williwonk’s, según lo que se describe en el problema 1. Estime las
ponderaciones de importancia. Incluya por lo menos un requerimiento y una restricción.
5. Cree una lista de requerimientos de los usuarios para la definición del problema que creó en el problema 4.
6. Delicato, Inc., un fabricante de instrumentos precisos de medición para fines científicos, le presentó una lista de
atributos que sus gerentes consideran que probablemente sean importantes para seleccionar un distribuidor de hardware
y software de computadora. Los criterios no se listan en orden de importancia.
1. Bajo precio.
2. Software escrito precisamente para aplicaciones de ingeniería.
3. El distribuidor realiza mantenimiento de rutina en el hardware.
4. Capacitación para los empleados de Delicato.
a. Critique la lista de atributos en un párrafo.
b. Use la entrada inicial para ayudar a Delicato, Inc., a generar una lista más adecuada de criterios para seleccionar
distribuidores de hardware y software.
7. SoftWear Silhouettes es una empresa de ventas por correo que está creciendo con rapidez y se especializa en ropa de
algodón. A la gerencia le gustaría expandir sus ventas al entorno Web mediante la creación de un sitio de comercio
electrónico. La empresa tiene dos analistas de sistemas que trabajan tiempo completo y un programador. Las oficinas dewww.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 95
Artículo Costos del sistema propuesto Costos del sistema actual
Año 1
Arrendamiento de equipo $20,000 $11,500
Salarios 30,000 50,000
Gastos generales 4,000 3,000
Desarrollo 30,000 —
Año 2
Arrendamiento de equipo $20,000 $10,500
Salarios 33,000 55,000
Gastos generales 4,400 3,300
Desarrollo 12,000 —
Año 3
Arrendamiento de equipo $20,000 $10,500
Salarios 36,000 60,000
Gastos generales 4,900 3,600
Desarrollo — —
Año 4
Arrendamiento de equipo $20,000 $10,500
Salarios 39,000 66,000
Gastos generales 5,500 4,000
Desarrollo — —
la empresa se encuentran en una pequeña ciudad aislada en Nueva Inglaterra y los empleados que se hacen cargo del
negocio tradicional de pedidos por correo no conocen mucho de computadoras.
a. Considerando la situación de la empresa, dibuje una lista de atributos de software en los que SoftWear Silhouettes
debería hacer énfasis a la hora de seleccionar el software para crear un sitio Web e integrar el negocio de pedidos por
correo con el negocio del sitio Web.
b. ¿Recomendaría usted software COTS, software personalizado o la subcontratación de un ASP? Indique su opción y
defiéndala en un párrafo.
c. Liste las variables que contribuyeron a su respuesta en el inciso b.
8. A continuación le presentamos la demanda de 12 años de Viking Village, un juego disponible en la actualidad para
equipos de bolsillo y teléfonos inteligentes (smartphones).
a. Grafique los datos de la demanda para Viking Village.
b. Determine la tendencia lineal para Viking Village mediante el uso de una media móvil de tres años.
9. ¿Parecen tener los datos para Viking Village una variación cíclica? Explique.
10. Interglobal Paper Company le ha pedido su ayuda para comparar su sistema computacional actual con uno nuevo que el
consejo de directores quisiera ver implementado. Los costos del sistema propuesto y del sistema actual son los siguientes:
Año Demanda
1998 20,123
1999 18,999
2000 20,900
2001 31,200
2002 38,000
2003 41,200
2004 49,700
2005 46,400
2006 50,200
2007 52,300
2008 49,200
2009 57,600
a. Use el análisis de punto de equilibrio para determinar el año en el que Interglobal Paper se
equilibrará.
b. Grafique los costos y muestre el punto de equilibrio.www.xlibros.com

96 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Año Beneficios
1 $55,000
2 75,000
3 80,000
4 85,000
11. A continuación se muestran los beneficios de sistemas para Interglobal Paper Company (del problema 10):
a. Use los costos del sistema propuesto de Interglobal Paper del problema 10 para determinar el periodo de retribución
(use el método de retribución).
b. Grafique los beneficios contra los costos e indique el periodo de retribución.
12. Glenn’s Electronics, una empresa pequeña, estableció un servicio de computadoras. La tabla que se muestra a
continuación muestra los ingresos esperados durante los primeros cinco meses de operación, además de los costos por
remodelación de oficinas, etcétera. Determine el flujo de efectivo y el flujo de efectivo acumulado para la empresa.
¿Cuándo se espera que Glenn’s muestre una ganancia?
Julio Agosto Septiembre Octubre Noviembre
Ingresos $35,000 $36,000 $42,000 $48,000 $57,000
Costos
Remodelación de oficina $25,000 $8,000
Salarios 11,000 12,100 $13,300 $14,600 $16,000
Capacitación 6,000 6,000
Arrendamiento de equipo 8,000 8,480 9,000 9,540 10,110
Provisiones 3,000 3,150 3,300 3,460 3,630
Año Costos Beneficios
1 $33,000 $21,000
2 34,600 26,200
3 36,300 32,700
4 38,100 40,800
5 40,000 51,000
6 42,000 63,700
13. Alamo Foods de San Antonio desea introducir un nuevo sistema computacional para su almacén de productos
perecederos. Los costos y beneficios de este sistema son:
a. Dada una tasa de descuento del 8 por ciento (.08), realice un análisis del valor presente con los datos para Alamo
Foods (sugerencia: use la fórmula
1
111 + i 2n
para encontrar los multiplicadores para los años 1 al 6).
b. ¿Cuál es su recomendación para Alamo Foods?
14. a. Suponga que la tasa de descuento en el problema 13a cambia al 13 por ciento (.13). Realice el análisis del valor
presente utilizando la nueva tasa de descuento.
b. ¿Cuál es su recomendación para Alamo Foods ahora?
c. Explique la diferencia entre el problema 13b y el problema 14b.
15. Resuelva el problema 13 usando un programa de hojas de cálculo electrónicas como Excel.
16. Use un programa de hojas de cálculo para resolver el problema 12.
17. Resuelva el problema 13 usando una función para el valor presente neto, como @NPV (x, rango) en Excel.
18. Brian C. O’Byrne (según él, la “C” significa “congelado”) es propietario de una empresa de comida congelada y desea
desarrollar un sistema de información para rastrear los envíos a los almacenes.
a. Use los datos de la tabla de la figura 3.EX1 para dibujar un gráfico de Gantt y ayudar a Brian a organizar su
proyecto de diseño.
b. ¿Cuándo sería apropiado usar un gráfico de Gantt? ¿Cuáles son las desventajas? Explique en un párrafo.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 97
19. Además de un gráfico de Gantt usted dibuja también un diagrama PERT para Brian, de forma que le pueda comunicar la
necesidad de mantener vigilada la ruta crítica. Consulte la figura 3.EJ2, que se derivó de los datos de la figura 3.EJ1.
Liste todas las rutas, calcule e identifique la ruta crítica.
Descripción
Dibujar el flujo de datos
Dibujar árbol de decisiones
Revisar árbol
Escribir proyecto
Organizar diccionario de datos
Realizar prototipo de salida
Revisar diseño de salida
Escribir casos de uso
Diseñar base de datos
Tarea
A
B
C
D
E
F
G
H
I
Va después de
Ninguna
A
B
C, I
A
Ninguna
F
Ninguna
H, E y G
Tiempo (semanas)
5
4
10
4
7
2
9
10
8
FIGURA 3.EX1
Datos para ayudar en la
organización de un proyecto de
diseño para crear un sistema
de información que rastrea los
envíos de comida congelada a los
almacenes.
Descripción
Entrevistar ejecutivos
Entrevistar personal en abastecimiento
de pedidos
Diseñar prototipo de entrada
Diseñar prototipo de salida
Escribir casos de uso
Registrar las reacciones del personal a
los prototipos
Desarrollar sistema
Escribir manual de capacitación
Capacitar al personal que trabaja en
el abastecimiento de pedidos
Tarea
A
B
C
D
E
F
G
H
I
Va después de
Ninguna
Ninguna
B
A, C
A, C
D
E, F
B, G
H
Tiempo (semanas)
6
3
2
3
4
2
5
3
2
FIGURA 3.EX3
Tareas a realizar durante el
desarrollo de un sistema de
abastecimiento de pedidos.
10
20
30
50
40
7060
A
F G
E
B
I
C
D
H
FIGURA 3.EX2
El diagrama PERT de la empresa
de comida congelada de Brian.
20. Cherry Jones es propietaria de una empresa de medicina homeopática llamada Fainthealers. Ella vende vitaminas y otros
productos relativamente no perecederos para quienes desean opciones relacionadas con la medicina alternativa. Cherry
está desarrollando un nuevo sistema en el que hay que volver a capacitar al personal. Dada la información de la figura
3.EJ3, realice un diagrama PERT para ella e identifique la ruta crítica. Si Cherry pudiera encontrar la forma de ahorrar
tiempo en la fase “escribir casos de uso”, ¿sería útil? ¿Por qué sí o por qué no?
21. Angus McIndoe quiere modernizar su popular restaurante, para lo cual piensa adaptarlo más a las preferencias de sus
clientes frecuentes: llevar el registro de lo que les gusta y disgusta. Por ende le interesa toda la información sobre los
lugares en los que les gusta sentarse, qué prefieren comer y a qué hora llegan por lo general, ya que piensa que de esta
forma podrá atender mejor a sus clientes. Angus le ha pedido a usted que desarrolle un sistema para él que le ayude a
mantener felices a sus clientes y, consecuentemente, mejorar su negocio.
Usted ha escuchado lo que Angus dijo sobre sus clientes. Sin duda hay más preferencias que puede rastrear.
Desarrolle la definición del problema para Angus, en forma similar a la que desarrolló para el Servicio de banquetes
de Catherine en este capítulo.
22. Hace poco, dos analistas recién egresados se unieron a su grupo de analistas de sistemas en la recién formada empresa
Mega Phone. Cuando hablaron con usted sobre el grupo, mencionaron que algunas cosas les parecen extrañas. Una de
ellas es que, aparentemente, los miembros del grupo admiran a dos líderes, Bill y Penny, y no sólo a uno.www.xlibros.com

98 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
Lo que observan es que Bill parece bastante relajado, mientras que Penny siempre está planeando y programando
actividades. También observaron que todos “simplemente parecen saber qué hacer” cuando entran a una reunión, incluso
cuando no se proporcionan instrucciones. Por último, resaltaron la apertura del grupo en cuanto a lidiar con los
problemas a medida que van surgiendo, en vez de dejar que las cosas se salgan de control.
a. A modo de explicación para los nuevos miembros del equipo, identifique los tipos de líderes que parecen ser Bill y
Penny, respectivamente.
b. Explique el enunciado de “todos simplemente parecen saber qué hacer”. ¿Qué es lo que guía su comportamiento?
c. ¿Qué concepto describe de una mejor manera la apertura del grupo que mencionaron los nuevos miembros del
equipo?
23. “Pienso que es justo escribir todas las alternativas que has considerado”, dice Lou Cite, un supervisor de personal
para Day-Glow Paints. “Después de todo, has estado trabajando en esta cosa de los sistemas durante un buen tiempo y
creo que tanto a mi jefe como a los demás les interesaría ver lo que averiguaste”. Usted está hablando con Lou al
tiempo que se prepara para elaborar la propuesta final de sistemas que su equipo presentará a la gerencia de nivel
superior.
a. En un párrafo explique a Lou por qué su propuesta no contendrá (y no debe hacerlo) todas las alternativas que su
equipo ha considerado.
b. En un párrafo hable sobre los tipos de alternativas que deben aparecer en la propuesta final de sistemas.
PROYECTOS EN GRUPO
1. Weil Smile Clinic es una clínica dental operada por los doctores Bonnie y Jeff; ellos necesitan mantener a salvo los datos
necesarios sobre sus pacientes y los seguros médicos. Investigaron sobre los respaldos en línea como SOS Online, Spare
Backup, Mozy Remote Backup y Data Deposit Box. Analice el costo de estos u otros servicios para después ayudar a los
doctores Bonnie y Jeff a tomar una decisión. ¿Cuáles son los costos y beneficios intangibles al respaldar información de
esta forma? ¿Deberían usar un sistema de respaldo o buscar alguna otra forma? Defienda su análisis y sus
recomendaciones.
2. Explore cuatro o cinco proveedores de voz sobre IP (VoIP). Haga una lista de los costos, incluyendo la cuota de
instalación, el costo mensual del plan básico, el costo mensual del plan ilimitado y el costo de un adaptador o cualquier
otra cuota requerida. Después elabore una lista de atributos como las llamadas gratis en la red, llamadas internacionales,
números telefónicos virtuales, teleconferencias, soporte para ID de llamadas, etcétera. Explique cómo podría utilizar una
persona toda la información cuantitativa y cualitativa para tomar una decisión informada sobre el proveedor de VoIP
adecuado. ¿Hay algunas otras variables importantes? ¿Recomendaría algún tipo de software para que ayude a comparar
estos servicios?
3. Seleccione un proveedor de VoIP con base en el análisis del proyecto en grupo 2.
4. Con los miembros de su equipo, explore el software de administración de proyectos como Microsoft Project. ¿Qué
características hay disponibles? Trabaje con su grupo para hacer una lista de ellas. Haga que su grupo evalúe la utilidad
del software para administrar un proyecto del equipo de análisis y diseño de sistemas. Indique en un párrafo si el
software que va a evaluar facilita la comunicación de los miembros el equipo y la administración de las actividades,
tiempo y recursos del equipo. Indique las características específicas que respaldan estos aspectos de cualquier proyecto.
Observe si el software no alcanza a cumplir estos criterios en cualquier aspecto.
5. Dibuje un diagrama de esqueleto de pescado sobre los posibles problemas que pueden ocurrir al construir un sitio Web
para una agencia de viajes que desea vender paquetes vacacionales en línea para el siguiente periodo extenso de
vacaciones (ya sea diciembre o junio).
BIBLIOGRAFÍA SELECCIONADA
Alter, S. Information Systems: The Foundation of E-Business, 4ta. Edición, Upper Saddle River, NJ: Prentice Hall, 2002.
Bales, R.F. Personality and Interpersonal Behavior, Nueva York: Holt, Rinehart y Winston, 1970.
Carnegie-Mellon Software Engineering Institute, “CBS Overview”. Disponible en: www.sei.cmu.edu/cbs/overview.html. Úl-
timo acceso: 15 de julio de 2009.
Construx Software Builders. Disponible en: www.construx.com. Último acceso: 15 de julio de 2009.
Sitio Web de Costar. Disponible en: www.softstarsystems.com. Último acceso: 15 de julio de 2009.
Glass, R. “Evolving a New Theory of Project Success”, Communications of the ACM, Vol. 42, Núm. 11, 1999, pp. 17-19.
Levine, D. M., P. R. Ramsey y M. L. Berenson. Business Statistics for Quality and Productivity. Upper Saddle River, NJ: Pren-
tice Hall, 1995.
Linberg, K. R. “Software Perceptions About Software Project Failure: A Case Study”. Journal of Systems and Software, Vol.
49, Núm. 2 y 3, 1999, pp. 177-92.
Longstreet Consulting, www.ifpug.org. Último acceso: 15 de julio de 2009.
McBreen, P. Questioning Extreme Programming. Boston: Addison-Wesley Co., 2003.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 99
Schein, E. H. Process Consultation: Its Role in Organization Development. Reading, MA: Addison-Wesley, 1969.
Shtub, A., J. F. Bard y S. Globerson. Project Management: Processes, Methodologies, and Economics, 3era. Edición. Upper
Saddle River, NJ: Pearson, 2005.
Software Product Research. Disponible en www.spr.com. Último acceso: 15 de julio de 2009.
Stefik, M., G. Foster, D. G. Bobrow, K. Kahn, S. Lanning y L. Suchman. “Beyond the Chalkboard: Computer Support for Co-
llaboration and Problem Solving in Meetings”. Communications of the ACM, Vol. 30, Núm. 1, enero 1987, pp. 32-47.
Vigder, M. R, W. M. Gentleman y J. C. Dean. “Using COTS Software in Systems Development”, http://www.nrc-cnrc.gc.ca/
eng/projects/iit/commercial-software.html. Último acceso: 15 de julio de 2009.
Walsh, B. “Your Network’s Not Ready for E-Commerce”, Network Computing. Disponible en: www.networkcomputing.
com/922/022colwalsh.html. Último acceso: 15 de julio de 2009.www.xlibros.com

100 PARTE I • FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS
E P I S O D I O 3
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. K ENDALL
Llegar a conocerte
Chip entra a la oficina de Anna un día y dice: “Creo que el proyecto será uno bueno, incluso aunque se está
tardando mucho en empezar”.
Anna quita la mirada de la pantalla y le sonríe. “Me gusta lo que has hecho para organizarnos”, dice.
“No sabía que Microsoft Visio y Visible Analyst podrían ayudarnos tanto con la administración del proyecto.
He decidido realizar un diagrama PERT para la parte de recolección de los datos del proyecto. Esto nos
ayudará a planear nuestro tiempo y trabajar como equipo en actividades paralelas”.
“¿Puedo dar un vistazo al diagrama PERT?”, pregunta Chip.
Anna le muestra una pantalla con un diagrama PERT (vea la figura E3.1) y comenta: “Esto nos ayudará
inmensamente. Es mucho más fácil que planear al azar”.
“Acabo de ver que tienes Recopilar informes, Recopilar registros y formularios de captura de datos, y
Recopilar documentos cualitativos como tareas paralelas”, observa Chip al tiempo que mira la pantalla.
“Sí”, le responde Anna. “Pensé que podríamos dividir el tiempo requerido para recopilar la informa-
ción. También podemos dividir la tarea de analizar lo que aprendimos”.
“Observé que tienes un número bastante extenso de días asignados para entrevistar a los usuarios”,
comenta Chip.
“Sí”, le responde Anna. “Esta actividad también incluye la creación de preguntas, ordenarlas en secuen-
cia y otras tareas, como tomar notas del entorno de oficina y analizarlas. También supuse un estándar de seis
horas productivas por día”.
“Después de entrevistar a los usuarios será conveniente crear una definición del problema para el sis-
tema, en donde se enlisten las cuestiones y objetivos”, continúa Anna. “Una vez terminada, haremos que los
usuarios la revisen y asignen ponderaciones. Al terminar, el siguiente paso es crear una lista de requerimien-
tos de los usuarios”.
“Parece un buen plan”, contesta Chip después de una pausa reflexiva. “¿Deberíamos empezar con una
lista de preguntas?”
Anna mira su reloj. “Ahora no; se está haciendo tarde. Creo que hemos progresado mucho en cuanto a
establecer nuestro proyecto. Terminemos por este día, o ¿debería decir por esta tarde? Recuerda que conse-
guí boletos para el juego de fútbol americano”.
Chip responde: “No lo había olvidado. Voy por mi abrigo y caminaremos juntos al estadio”.
Al caminar por el campus más tarde, Chip dice: “Estoy emocionado. Es mi primer juego aquí en la
CPU. Por cierto ¿cuál es la mascota del equipo?”
“Ardillas, por supuesto”, dice Anna.
“¿Y los colores del equipo?” pregunta Chip al momento en que entran al estadio.
“Azul y blanco”, le responde Anna.
“Oh, entonces esa es la razón por la que todos gritan, ‘¡Vamos, Gran Azul!’” dice Chip, al escuchar el
rugido de la multitud.
“Exacto”, dice Anna.
C, ,1
A, 4
B, 5
E 2
F, 4
D, 6
G, 15 I, 4
H, 14 J, 3
K, 15
20
3010 50 60 80 90
40 70
A Recopilar informes
B Recopilar registros y formularios de captura de datos
C Recopilar documentos cualitativos
D Analizar informes
E Comprender la cultura de la organización
F Analizar registros y formularios
G Entrevistar a los usuarios
H Administrar cuestionarios
I Sintetizar las entrevistas
J Sintetizar los resultados de las encuestas
K Sistema de prototipos
FIGURA E3.1
Un diagrama PERT para Central
Pacific University que se utiliza
para recopilar información.www.xlibros.com

CAPÍTULO 3 • ADMINISTRACIÓN DE PROYECTOS 101
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver el diagrama PERT de recopilación de información
(Gathering Information).
E-2. Haga una lista de todas las rutas; además calcule y determine la ruta crítica para el diagrama PERT
de recopilación de información.
E-3. Use Microsoft Visio o Visible Analyst para crear el diagrama PERT que se muestra en la figura E3.2. Este
diagrama representa las actividades involucradas en las entrevistas a los usuarios y observar sus oficinas.
A, 1 B, 1 C, 2 E, 3
D, 1
8
F, 4 G, 2
H, 1
I, 2
10 20 30 40 60
70
80
50
Actividad simulada
A
B
C
D
E
F
G
H
I
Escribir objetivos
Determinar a quién entrevistar
Escribir preguntas
Preparar al entrevistado
Entrevistar a la administración superior
Entrevistar a la administración de operaciones
Registrar y analizar las observaciones
Sintetizar las entrevistas a la administración
Sintetizar las entrevistas al personal de operaciones
FIGURA E3.2
Un diagrama PERT para Central
Pacific University que se utiliza
para la fase de entrevistas a los
usuarios.
DuraciónPredecesorActividad
Determinar pantallas e informes
del prototipo general
Determinar contenidos de informes y pantallas
Crear prototipos de los informes
Crear prototipos de las pantallas
Obtener retroalimentación de los prototipos de
los informes
Obtener retroalimentación de los prototipos de
las pantallas
Modificar prototipos de los informes
Modificar prototipos de las pantallas
Obtener la aprobación final
A
B
C
D
E
F
G
H
I
Ninguno
A
B
B
C
D
E
F
G, H
2
4
3
4
1
2
2
4
2
FIGURA E3.3
Una lista de actividades y tiempos
de duración estimados para el
proyecto de la CPU.
E-4. Elabore una lista de todas las rutas; además calcule y determine la ruta crítica para el diagrama PERT
de entrevistas a los usuarios (Interviewing Users).
E-5. Use Visio o Visible Analyst para crear un diagrama PERT que genere prototipos de sistemas. La in-
formación de actividades se muestra en la figura E3.3.
E-6. Cree la definición del problema para el caso de la CPU. Lea la entrevista con Hy Perteks en el caso
de la CPU que se encuentra en el capítulo 4, así como las entrevistas en el sitio Web de soporte para
el libro. Vaya a www.pearsonhighered.com/kendall y haga clic en el vínculo CPU Student Exercise
(ejercicio de la CPU para estudiantes) para el libro de la 8va. edición. Después haga clic en el primer
vínculo llamado CPU Interviews (entrevistas de la CPU). Tendrá que leer las cinco entrevistas adi-
cionales. Hay un vínculo Next (Siguiente) en la esquina inferior derecha de la página Web para pasar
a la siguiente entrevista.
E-7. Escriba los requerimientos de los usuarios para el caso de la CPU.
E-8. Diseñe un plan de prueba para los requerimientos creados en el ejercicio E-7.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.
pearsonhighered.com/kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Ana-
lyst, Microsoft Project o Microsoft Access que pueden usar para completar los ejercicios.www.xlibros.com

www.xlibros.com

103
C A P Í T U L O 4
Recopilación de información:
métodos interactivos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Reconocer el valor de los métodos interactivos para recopilar información.
2. Elaborar preguntas para conocer mediante entrevistas los requerimientos humanos de
información.
3. Estructurar las entrevistas de una manera significativa para los usuarios.
4. Comprender el concepto de JAD y cuándo hay que usarlo.
5. Redactar preguntas efectivas para entrevistar a los usuarios sobre su trabajo.
6. Diseñar y administrar cuestionarios efectivos.
Hay tres métodos interactivos clave que puede usar para obtener los requeri-
mientos humanos de información de los miembros de la organización: entre-
vistas, diseño de aplicaciones conjuntas (JAD) y encuestas aplicadas a las
personas mediante cuestionarios. Aunque son distintos en su implementación,
estos métodos tienen muchas cosas en común. La base de sus propiedades
compartidas es hablar con las personas en la organización y escucharlas para comprender sus in-
teracciones con la tecnología, a través de una serie de preguntas cuidadosamente elaboradas.
Cada uno de los tres métodos interactivos para recopilar información cuenta con su propio
proceso establecido; usted debe seguirlo para interactuar con los usuarios. La observancia de
estas metodologías sistemáticas ayudan a asegurar el diseño y la implementación apropiados
de las entrevistas, los talleres de trabajo de JAD y los cuestionarios; además respaldarán un
análisis lúcido de los datos resultantes. En un capítulo posterior veremos los métodos discretos
(muestreo, investigación y observación del comportamiento del encargado de tomar las deci-
siones junto con su entorno físico) que no requieren el mismo grado de interactividad entre
analistas y usuarios. El uso de métodos interactivos con métodos no discretos le permitirá ob-
tener una descripción más completa de los requerimientos de información de la organización.
P A R T E I I
Análisis
de los requerimientos
de información
ENTREVISTAS
Es conveniente que se entreviste a usted mismo antes de hacerlo con alguien más. Necesita
reconocer sus predisposiciones y la forma en que éstas afectarán a sus percepciones. Su educa-
ción, intelecto, crianza, emociones y marco ético constituyen filtros relevantes para lo que usted
escuchará en sus entrevistas.
Piense en el proceso completo de la entrevista antes de llevarla a cabo. Visualice por qué la hará,
las preguntas que formulará y qué la convertirá en una entrevista exitosa de acuerdo con su criterio.
Además debe planear cómo hacer de la entrevista un suceso satisfactorio para el entrevistado.
Una entrevista para recopilar información es una conversación dirigida con un propósito
específico, en la cual se usa un formato de preguntas y respuestas. En la entrevista hay que ob-
tener las opiniones del entrevistado y lo que siente sobre el estado actual del sistema, los obje-
tivos de la organización y los personales, y los procedimientos informales para interactuar con
las tecnologías de la información.www.xlibros.com

104 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
1. Leer el material sobre los antecedentes.
2. Establecer los objetivos de la entrevista.
3. Decidir a quién entrevistar.
4. Preparar al entrevistado.
5. Decidir sobre los tipos de preguntas y su estructura.
Pasos para planear la entrevista
FIGURA 4.1
Pasos que debe seguir el analista
de sistemas para planear la
entrevista.
Sobre todo busque las opiniones del entrevistado. Éstas pueden ser más importantes y reveladoras que los
hechos. Por ejemplo, suponga que pregunta a la propietaria de una tienda convencional, quien acaba de instau-
rar una tienda en línea, cuántos clientes piden comúnmente el reembolso de sus transacciones vía Web cada
semana. Ella le responde: “Entre 20 y 25 por semana”. Cuando usted supervisa las transacciones y descubre
que el promedio es de sólo 10.5 por semana, tal vez concluya que la propietaria está exagerando los hechos y
el problema.
Ahora imagine que en vez de lo anterior pregunta a la propietaria cuáles son sus principales preocupaciones
y ella le contesta: “En mi opinión, las devoluciones de los clientes que compran artículos a través del sitio Web
son demasiado altas”. Al buscar opiniones en vez de hechos, descubrió un problema clave que la propietaria de-
sea solucionar.
Además de las opiniones hay que tratar de capturar los sentimientos del entrevistado. Recuerde que éste
conoce mejor la organización que usted. Para que usted pueda entender mejor la cultura de organización debe
escuchar los sentimientos del que responde a la entrevista.
Los objetivos son información importante que podemos obtener de las entrevistas. Los datos “duros” pueden
explicar el desempeño en el pasado, pero los objetivos proyectan el futuro de la organización. Trate de averiguar
a través de las entrevistas la mayor cantidad posible de objetivos de la organización, pues tal vez no pueda deter-
minarlos mediante los otros métodos de recopilación de datos.
La entrevista también es un valioso momento para explorar las cuestiones sobre HCI (interacción humano-
computadora), incluyendo los aspectos ergonómicos, la capacidad de uso del sistema, qué tan placentero y diver-
tido es el sistema, y qué tan útil es para apoyar las tareas individuales.
En la entrevista debemos establecer una relación con un extraño. Hay que generar confianza y compren-
sión rápidamente y, al mismo tiempo, mantener el control de la entrevista. También necesitamos vender el
sistema, para lo cual hay que proveer información necesaria al entrevistado. Planear previamente la entrevista
le facilitará dirigirla. Por fortuna podemos aprender a realizar entrevistas en forma efectiva. A medida que
practique, usted mismo podrá ver cómo va mejorando. Más adelante en el capítulo hablaremos sobre el diseño
de aplicaciones conjuntas (JAD), que nos puede servir como alternativa a las entrevistas cara a cara en ciertas
situaciones.
Los cinco pasos para la preparación de una entrevista
En la figura 4.1 se muestran los cinco pasos principales en la preparación para una entrevista; incluyen activida-
des que van desde recopilar material sobre antecedentes básicos hasta decidir a quién vamos a entrevistar.
ENTÉRESE DE LOS ANTECEDENTES Lea y comprenda todo lo que pueda sobre los antecedentes de los entrevistados
y la organización. El sitio Web corporativo, un informe anual actualizado, un boletín de noticias corporativo o
cualquier publicación que se emita para explicar el funcionamiento de la empresa al público son fuentes útiles de
información. Puede revisar en Internet cualquier información corporativa, como la que se encuentra en Standard
and Poor’s.
En esta fase de investigación ponga especial atención al lenguaje utilizado por los integrantes corporativos
para describirse a sí mismos y a la compañía. Trate de recopilar un vocabulario común que le permita expresar
preguntas de forma que sus entrevistados puedan comprender inmediatamente. Otro beneficio de investigar la
organización es aprovechar al máximo el tiempo invertido en las entrevistas, al no tener que hacer preguntas ge-
nerales sobre antecedentes.
ESTABLEZCA LOS OBJETIVOS DE LA ENTREVISTA Defina los objetivos de la entrevista a partir de los antecedentes
investigados y de su propia experiencia. Debe haber de cuatro a seis áreas clave concernientes a HCI, el
procesamiento de información y el comportamiento de los encargados de tomar las decisiones, sobre lo cual será
conveniente interrogar. Estas áreas incluyen cuestiones sobre HCI (la utilidad y capacidad de uso del sistema,
cómo se ajusta a los aspectos físicos, cómo se adapta a las capacidades cognitivas de un usuario, si es interesantewww.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 105
Preguntas abiertas en las entrevistas
• ¿Qué opina sobre el estado actual del comercio electrónico de negocio a
negocio en su empresa?
• ¿Cuáles son los objetivos críticos de su departamento?
• Una vez que se envían los datos a través del sitio Web, ¿cómo se procesan?
• Describa el proceso de monitoreo disponible en línea.
• ¿Cuáles son algunos de los errores comunes al introducir datos que se
cometen en este departamento?
• ¿Cuáles son las mayores frustraciones que ha experimentado durante la
transición al comercio electrónico?
FIGURA 4.2
Las preguntas abiertas en las
entrevistas ofrecen opciones
abiertas para que el entrevistado
responda. Los ejemplos se
seleccionaron de distintas
entrevistas y no se muestran en
ningún orden específico.
o estéticamente atractivo, y si al utilizar el sistema se obtienen o no las consecuencias deseadas), fuentes de
información, formatos de información, frecuencia de la toma de decisiones, calidades de la información y el
estilo de la toma de decisiones.
DECIDA A QUIÉN ENTREVISTAR Incluya personas clave de todos los niveles que se vean afectados por el sistema
en cierta forma. Trate de que la muestra sea representativa para indagar sobre la mayor cantidad posible de
necesidades de usuario. Su contacto de la organización también le puede dar ideas sobre las personas que debe
entrevistar.
PREPARE AL ENTREVISTADO Para preparar a la persona que va a entrevistar, llame por teléfono o envíe un
mensaje de correo electrónico con anticipación, de manera que el entrevistado esté preparado; si la entrevista es
muy detallada, envíe previamente el cuestionario por correo electrónico para que el entrevistado pueda pensar
en sus respuestas. En todo caso, como hay que cumplir muchos objetivos en la entrevista (como crear confianza
y observar el lugar de trabajo), las entrevistas se deben realizar por lo general en persona y no a través de
correo electrónico. Deben durar de 45 minutos a 1 hora como máximo. Sin importar cuánto se quieran extender
los entrevistados más allá de ese límite, recuerde que cuando invierten tiempo con usted no están haciendo
su trabajo. Si las entrevistas exceden de una hora, es probable que los entrevistados resientan la intrusión,
independientemente de si se lo hacen saber o no.
DECIDA SOBRE LOS TIPOS DE PREGUNTAS Y SU ESTRUCTURA Redacte preguntas para cubrir las áreas clave de
la HCI y el proceso de toma de decisiones que haya descubierto al momento de determinar los objetivos de la
entrevista. Las técnicas de interrogación apropiadas son la base de la entrevista. Las preguntas tienen ciertas
formas básicas que necesitamos conocer. Los dos tipos básicos de preguntas son abiertas y cerradas. Cada tipo
de pregunta puede lograr algo ligeramente distinto que los otros, y cada uno tiene sus beneficios y desventajas.
Debe pensar sobre el efecto que cada tipo de pregunta tendrá.
Es posible estructurar la entrevista en tres patrones: estructura de pirámide, estructura de embudo o estruc-
tura de diamante. Cada estructura es apropiada bajo distintas condiciones y sirve a un propósito diferente; habla-
remos sobre cada una de ellas más adelante en este capítulo.
Tipos de preguntas
PREGUNTAS ABIERTAS Las preguntas abiertas son del tipo: “¿Qué piensa en cuanto a poner a todos los
gerentes en una intranet?”, “Por favor explique cómo toma una decisión sobre la programación de tiempos
y fechas.”, “¿En qué formas extiende el sistema su capacidad de realizar tareas que no sería posible realizar
mediante algún otro medio?”. Abiertas describe las opciones que tiene el entrevistado para responder. La
respuesta puede constar de dos palabras o de dos párrafos. En la figura 4.2 se muestran algunos ejemplos de
preguntas abiertas.
Los beneficios de utilizar preguntas abiertas son muchos, entre los cuales tenemos:
1. El entrevistado baja la guardia.
2. El entrevistador puede percibir el vocabulario del entrevistado, lo cual refleja su educación, valores, posturas
y creencias.
3. Se proveen muchos detalles.
4. Se descubren vías de cuestionamiento adicionales que de otra manera no se hubieran explotado.
5. El entrevistado encuentra el proceso más interesante.
6. Se permite una mayor espontaneidad.www.xlibros.com

106 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Preguntas bipolares en entrevistas
• ¿Usa la Web para proveer información a los distribuidores?
• ¿Está de acuerdo o en desacuerdo en cuanto a que el comercio
electrónico en Web carece de seguridad?
• ¿Desea recibir un documento impreso de su estado de cuenta cada mes?
• ¿Mantiene su sitio Web una página de preguntas frecuentes (FAQ) para
los empleados con preguntas sobre su nómina?
• ¿Está completo este formulario?
FIGURA 4.4
Las preguntas bipolares en las
entrevistas son un tipo especial de
pregunta cerrada. Los ejemplos se
seleccionaron de distintas
entrevistas y no se muestran en
ningún orden específico.
Preguntas cerradas en entrevistas
• ¿Cuántas veces por semana se actualiza el repositorio del proyecto?
• En promedio, ¿cuántas llamadas recibe el centro de atención al mes?
• ¿Cuál de las siguientes fuentes de información es más valiosa para usted?
° Formularios completos de quejas de los clientes
° Quejas por correo electrónico de los consumidores que visitan el sitio Web
° Interacción cara a cara con los clientes
° Mercancía devuelta
• Enliste sus dos principales prioridades para mejorar la infraestructura de tecnología.
• ¿Quién recibe esta entrada?
FIGURA 4.3
Las preguntas cerradas en las
entrevistas limitan las opciones del
que responde. Los ejemplos se
seleccionaron de distintas
entrevistas y no se muestran en
ningún orden específico.
7. El entrevistador puede expresar mejor las preguntas.
8. El entrevistador puede recurrir a ellas en caso de que tenga que improvisar.
Como puede ver, hay varias ventajas en cuanto al uso de preguntas abiertas. Sin embargo, también hay muchas
desventajas:
1. Las preguntas pueden generar muchos detalles irrelevantes.
2. Se puede llegar a perder el control de la entrevista.
3. Se permiten respuestas que pueden requerir demasiado tiempo debido a la cantidad obtenida de información
útil.
4. Podría parecer que el entrevistador no está preparado.
5. Puede darse la impresión de que el entrevistador “anda de pesca”, sin objetivos bien definidos.
Debe considerar con cuidado las implicaciones de usar preguntas abiertas en las entrevistas.
PREGUNTAS CERRADAS La otra alternativa la constituyen las preguntas cerradas; asumen las formas básicas “¿Es
fácil usar el sistema actual?” y “¿Cuántos subordinados tiene a su cargo?”. Las posibles respuestas son cerradas
para el entrevistado, debido a que sólo puede responder con un número finito tal como “Ninguna”, “Una” o
“Quince”. En la figura 4.3 se muestran ejemplos de preguntas cerradas.
Una pregunta cerrada limita el entrevistado la respuesta disponible. Tal vez usted esté familiarizado con las
preguntas cerradas debido a los exámenes de opción múltiple de la universidad. Se le proporciona una pregunta y
cinco respuestas, y no puede anotar una respuesta propia ya que se considerará equivocada.
Hay un tipo especial de pregunta cerrada: la pregunta bipolar. Este tipo de pregunta limita incluso más al
entrevistado, ya que sólo le permite elegir uno de dos polos, como sí o no, verdadero o falso, de acuerdo o en
desacuerdo. En la figura 4.4 se muestran ejemplos de preguntas bipolares.
Los beneficios de usar preguntas cerradas de cualquier tipo incluyen:
1. Ahorro de tiempo.
2. Se pueden comparar las entrevistas con facilidad.
3. Van directo al grano.
4. Se mantiene el control sobre la entrevista.
5. Se cubre mucho terreno con rapidez.
6. Se obtienen datos relevantes.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 107
Sin embargo, las desventajas de usar preguntas cerradas son substanciales. Entre las más comunes tenemos:
1. Son aburridas para el entrevistado.
2. No proporcionan detalles adicionales (debido a que el entrevistador provee el marco de referencia para el
entrevistado).
3. Se pierden las ideas principales por la razón anterior.
4. No se puede generar una buena comunicación entre el entrevistador y el entrevistado.
Por lo tanto, como entrevistador usted debe considerar con cuidado los tipos de preguntas que piensa utilizar.
Tanto las preguntas abiertas como las cerradas tienen ventajas y desventajas, como se muestra en la figura
4.5. Tenga en cuenta que se deben hacer ciertas concesiones al elegir un tipo de respuesta en vez del otro; aunque
una pregunta abierta ofrece amplitud y profundidad en la respuesta, este tipo de respuestas son más difíciles de
analizar.
SONDEOS El tercer tipo de pregunta es el sondeo o seguimiento. El sondeo más sólido es el más simple: la
pregunta “¿Por qué?”. Otros sondeos son: “¿Me puede dar un ejemplo de un momento en el que el sistema no
le haya parecido confiable?” y “¿Podría explicarme eso?”. En la figura 4.6 se muestran ejemplos de preguntas
de sondeo. El propósito del sondeo es ir más allá de la respuesta inicial para obtener más detalles significativos,
aclarar la información, y ampliar el punto del entrevistado. Los sondeos pueden ser preguntas abiertas o
cerradas.
Es imprescindible realizar sondeos. La mayoría de los entrevistadores principiantes son reticentes en cuanto
a realizar sondeos y con frecuencia aceptan respuestas superficiales. Por lo general están más agradecidos por el
hecho de que los entrevistados hayan concedido las entrevistas y se sienten en parte obligados a aceptar declara-
ciones sin argumentos con amabilidad.
Ordenar las preguntas en una secuencia lógica
Así como hay dos formas generalmente reconocidas de razonamiento (inductivo y deductivo), también hay dos
formas similares de organizar las entrevistas. Además existe una tercera forma que combina los patrones induc-
tivo y deductivo.
CerradasAbiertas
Bajo
Bajo
Bajo
Mucha
Mucha
Difícil
Alto
Alto
Alto
Poca
Poca
FácilFacilidad de análisis
Confiabilidad de los datos
Uso eficiente del tiempo
Precisión de los datos
Amplitud y profundidad
Se requiere habilidad del entrevistador
FIGURA 4.5
Atributos de las preguntas abiertas
y las preguntas cerradas.
Sondeos
•
•
•
•
•
•
¿Por qué?
Mencione un ejemplo de cómo se ha integrado el comercio electrónico en
sus procesos de negocios.
Ilustre el tipo de problemas de seguridad que experimenta con su sistema
de pagos de facturas en línea.
Mencionó una solución tanto de intranet como de extranet. Por favor muestre
un ejemplo de la forma en que piensa que difiere cada una de estas soluciones.
¿Qué lo hace sentir así?
Dígame paso a paso qué ocurre después de que un cliente hace clic en el
botón “Enviar” en el formulario de registro Web.
FIGURA 4.6
Los sondeos permiten al analista
de sistemas dar seguimiento a las
preguntas para obtener respuestas
más detalladas. Los ejemplos se
seleccionaron de distintas
entrevistas y no se muestran en
ningún orden específico.www.xlibros.com

108 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
USO DE UNA ESTRUCTURA DE PIRÁMIDE La organización inductiva de las preguntas de la entrevista se puede
visualizar en forma de pirámide. El entrevistador empieza con preguntas muy detalladas, a menudo cerradas. Después
expande los temas al permitir preguntas abiertas y respuestas más generalizadas, como se muestra en la figura 4.7.
Utilice una estructura de pirámide si cree que su entrevistado necesita entrar en calor en cuanto al tema.
También es conveniente usar una estructura de pirámide para las secuencias de preguntas si desea una determina-
¿Cuál es
el problema
específico que está
experimentando
con su firewall?
¿Ha considerado otros
métodos para mejorar la seguridad
de los datos corporativos?
De acuerdo con su punto de vista,
¿qué mejoraría la efectividad de la seguridad aquí?
En general, ¿cómo se siente en cuanto a la seguridad de los
datos en comparación con la importancia del acceso a Internet?
Las estructuras
de pirámide empiezan
con una pregunta
específica...
... y terminan con
una pregunta
general.
FIGURA 4.7
La estructura de pirámide para las
entrevistas pasa de preguntas
específicas a generales.
O P O R T U N I D A D D E C O N S U L T O R Í A 4 . 1
Fortalezca sus tipos de preguntas
Strongbodies, una enorme cadena local de clubes deportivos, ha
experimentado un crecimiento fenomenal en los últimos cinco años.
A la gerencia le gustaría refinar su proceso de toma de decisiones
para comprar nuevo equipo de fisicoculturismo. En la actualidad,
los gerentes escuchan a los clientes, asisten a exposiciones, ven
anuncios publicitarios y solicitan la compra de nuevos equipos con
base en sus percepciones subjetivas. Después, Harry Mussels se
encarga de aprobar o rechazar estas solicitudes.
Harry es la primera persona a quien entrevistará. Es un gerente
de división de 37 años que dirige cinco clubes en el área. Viaja por
toda la ciudad para visitar sus ubicaciones esparcidas ampliamente.
Tiene una oficina en la ubicación este, aunque está ahí menos de una
cuarta parte del tiempo.
Además, cuando Harry se encuentra en un club está ocu-
pado contestando llamadas telefónicas relacionadas con los ne-
gocios, resolviendo problemas inmediatos que le presentan los
gerentes e interactuando con los miembros del club. Cuenta con
poco tiempo y, para compensar, se ha convertido en un gerente
divisional en extremo organizado y eficiente. No le puede con-
ceder mucho tiempo en la entrevista. Pero su aportación es im-
portante y siente que sería el principal beneficiario del sistema
propuesto.
¿Qué tipo de pregunta sería el más adecuado para su entre-
vista con Harry? ¿Por qué sería el tipo más apropiado? ¿Cómo
afectará el tipo de pregunta que usted seleccione en la cantidad de
tiempo que invertirá en su preparación para entrevistar a Harry?
Escriba de 5 a 10 preguntas de este tipo. ¿Qué otras técnicas po-
dría utilizar para complementar la información que no esté dispo-
nible por medio de ese tipo de pregunta? Escriba un párrafo para
explicar.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 109
ción final sobre el tema. Tal es el caso en la pregunta final: “En general, ¿cómo se siente en cuanto a la seguridad
de los datos en comparación con la importancia del acceso a Internet?”.
USO DE UNA ESTRUCTURA DE EMBUDO En el segundo tipo de estructura, el entrevistador usa un enfoque
deductivo al empezar con preguntas generalizadas y abiertas, para después reducir la cantidad de respuestas
posibles mediante el uso de preguntas cerradas. Esta estructura de entrevista se puede representar en forma
de embudo, como se muestra en la figura 4.8. El método de la estructura de embudo ofrece una manera fácil
y amigable de empezar una entrevista. También es conveniente usar una secuencia de preguntas en forma de
embudo cuando el entrevistado está relacionado sentimentalmente con el tema y necesita libertad para expresar
esos sentimientos.
USO DE UNA ESTRUCTURA EN FORMA DE DIAMANTE A menudo es mejor utilizar una combinación de las
dos estructuras anteriores, a lo cual se le conoce como estructura de entrevista en forma de diamante. En esta
estructura la entrevista empieza de una manera muy específica y después se examinan las cuestiones generales,
para finalmente llegar a una conclusión muy particularizada, como se muestra en la figura 4.9.
El entrevistador empieza con preguntas fáciles y cerradas que permiten al entrevistado entrar en calor; a
la mitad se le pregunta lo que opina sobre temas amplios que obviamente no tienen sólo una respuesta “co-
rrecta”. Después, el entrevistador restringe incluso más las preguntas para obtener respuestas específicas, con
lo cual se produce un cierre tanto para el entrevistado como para el entrevistador. La estructura de diamante
combina las ventajas de los otros dos métodos pero tiene la desventaja de que toma más tiempo que las otras
dos estructuras.
El final de la entrevista parecería un punto lógico para hacer una pregunta clave —“¿Hay algo de lo que no
hayamos hablado que usted considere importante?”—, pero como el entrevistado la considera una pregunta de
fórmula, la mayor parte de las ocasiones la respuesta será “No”. Por ende, usted debe identificar las coyunturas
en que esta pregunta pueda soltarle la lengua al entrevistado.
Al concluir la entrevista, haga un resumen y provea retroalimentación sobre sus impresiones en general. In-
forme al entrevistado sobre los pasos a seguir, y lo que harán usted y los demás miembros del equipo a continua-
ción. Pregunte al entrevistado con quién debería usted hablar en adelante. Establezca citas para dar seguimiento a
las entrevistas, agradezca al entrevistado por su tiempo y despídase de mano.
Cómo escribir el informe de la entrevista
Aunque la entrevista esté completa, apenas empieza su trabajo sobre los datos que obtuvo. Necesita capturar la
esencia de la entrevista por medio de un informe escrito. Es imperativo que escriba el informe tan pronto como
sea posible después de la entrevista. Este paso es otra manera en la que puede asegurar la calidad de los datos
obtenidos de la entrevista: entre más tiempo espere para escribir su entrevista, más borrosa se volverá la calidad
de sus datos.
¿Qué artículos se podrán comprar
en el sitio Web?
¿Cuáles son sus reacciones en cuanto al nuevo
sistema de adquisiciones basado en Web?
¿Hay algún artículo esencial
que se haya excluido
del sitio?
Las estructuras de
embudo empiezan
con una pregunta
general ...
... y terminan con
una pregunta
específica.
¿ Q u é d e p a r t a m e n t o s e s t á n i n v o l u c r a d o s e n s u
i m p l e m e n t a c i ó n ?
FIGURA 4.8
La estructura de embudo para las
entrevistas empieza con preguntas
amplias y después se restringe a
preguntas específicas.www.xlibros.com

110 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U L T O R Í A 4 . 2
Un vistazo a la superficie
Está a punto de salir de la lechería SureCheck Dairy, después de
un recorrido preliminar, cuando otro miembro de su equipo de aná-
lisis de sistemas le llama para decirle que, por enfermedad, no podrá
presentarse para entrevistar al gerente de la planta, como lo había
convenido. El gerente es una persona muy ocupada y usted desea
mantener su entusiasmo por el proyecto haciendo las cosas según lo
planeado. También se da cuenta de que sin los datos de la entrevista
inicial, se atrasará el resto del proceso de recopilación de datos.
Aunque no tiene preparadas las preguntas para la entrevista, decide
ir y entrevistar al gerente de la planta en el acto.
Lo que usted ha aprendido sobre SureCheck es que están inte-
resados en procesar sus propios datos sobre las cantidades y tipos
de productos lácteos que se venden, de manera que el personal
pueda utilizar esa información para controlar mejor la producción
de la extensa línea de productos de la empresa (leche entera, descre-
mada, con 1% de grasa, con 2% de grasa, mitad y mitad, queso
cottage, yogurt y productos congelados novedosos). En la actuali-
dad, los gerentes de ventas envían sus cifras a las oficinas generales,
situadas a 600 millas, y el ciclo de procesamiento de las mismas se
ve lento. Usted basará sus preguntas improvisadas en lo que acaba
de descubrir en el recorrido.
Durante los pocos minutos que quedan antes de la hora de la
entrevista, decida la estructura que utilizará (de embudo, de pirá-
mide o de diamante). Justifique en un párrafo su elección conside-
rando las inesperadas condiciones. Escriba una serie de preguntas y
organícelas en la estructura que eligió.
¿Cuáles son
los cinco tipos de
información que rastrea el
servicio gratuito de uso de
sitios Web que usted utiliza?
¿Cuáles son las actividades promocionales que
usted ofrece en su sitio a cambio de este servicio?
¿Cuál es el valor de la información sobre el uso de
su sitio Web para usted como webmaster?
¿Cuáles son dos puntos sorprendentes en relación con el
comportamiento de los usuarios en su sitio que haya
descubierto mediante el uso de este servicio?
¿Son los “cookies” una mejor
forma de medir la forma en
que los usuarios finales
utilizan el sitio?
Las estructuras
de diamante
empiezan con una
pregunta específica ...
... pasan a
preguntas
generales ...
... y terminan con
una pregunta
específica.
FIGURA 4.9
La estructura en forma de
diamante para las entrevistas
combina las estructuras de
pirámide y de embudo.
Después de este resumen inicial, elabore otro más detallado donde exprese los puntos principales de la en-
trevista y sus propias opiniones. Revise el informe con el entrevistado en una reunión de seguimiento. Este paso
ayuda a aclarar el significado que tenía el entrevistado en mente y le hace saber que usted tiene el suficiente inte-
rés como para tomarse el tiempo de comprender su punto de vista y sus percepciones.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 111
DISEÑO DE APLICACIÓN CONJUNTA
Sin importar qué tan experto se vuelva como entrevistador, se cruzará con situaciones en las que las entre-
vistas cara a cara no resulten tan convenientes como esperaba. Las entrevistas personales consumen tiempo
y son propensas a errores, por lo cual sus datos se pueden malinterpretar. IBM desarrolló una metodología
alternativa para entrevistar a los usuarios uno a uno, conocida como diseño de aplicación conjunta (JAD).
Los motivos para usar JAD son reducir el tiempo (y por ende el costo) requerido por las entrevistas perso-
nales, mejorar la calidad de los resultados de la evaluación de los requerimientos de información y mejorar
el grado de identificación del usuario con los nuevos sistemas de información como resultado de los proce-
sos participativos.
Aunque JAD se puede sustituir por las entrevistas personales en cualquier momento apropiado durante
el SDLC, por lo general se emplea como técnica que le permite a usted, como analista de sistemas, realizar el
análisis de requerimientos y diseñar la interfaz de usuario en forma conjunta con los usuarios, en un ambiente
de grupo. Las diversas complejidades de esta metodología se pueden aprender sólo en un seminario pagado
en el que se demuestren métodos propietarios. No obstante, aquí proporcionamos orientación suficiente para
que usted conozca algunos de sus beneficios y desventajas en comparación con las entrevistas cara a cara.
Condiciones que respaldan el uso de JAD
La siguiente lista de condiciones le ayudará a decidir cuándo puede ser fructífero el uso de JAD. Considere el
uso del diseño de aplicación conjunta cuando:
1. Los grupos de usuarios estén inquietos y deseen algo nuevo, no una solución estándar para un problema
común.
2. La cultura de la organización apoya los comportamientos de solución de problemas conjuntos entre varios
niveles de empleados.
3. Los analistas pronostican que la cantidad de ideas generadas mediante las entrevistas cara a cara no será tan
abundante como el número de ideas posibles mediante un ejercicio de grupo extendido.
4. El flujo de trabajo permita la ausencia del personal clave durante un periodo de dos a cuatro días.
¿Quién está involucrado?
Las sesiones de diseño de aplicaciones conjuntas incluyen a varios participantes (analistas, usuarios, ejecutivos,
etcétera), quienes aportarán sus distintos antecedentes y capacidades. Su principal preocupación aquí es que to-
dos los miembros del equipo del proyecto se comprometan con la metodología JAD. Seleccione un patrocinador
ejecutivo, algún superior que introduzca y concluya la sesión JAD. De preferencia seleccione un ejecutivo del
grupo de usuarios que tenga cierto tipo de autoridad sobre el personal de sistemas de información implicado en
el proyecto. Esta persona será un símbolo importante y visible del compromiso de la organización con el pro-
yecto de sistemas.
Debe haber por lo menos un analista de sistemas de información presente, aunque por lo general asume un
rol pasivo, a diferencia de las entrevistas tradicionales, donde el analista controla la interacción. Como analista
del proyecto, usted debería estar presente durante el JAD para escuchar qué dicen los usuarios y qué requieren.
Además podría ser necesaria su opinión experta sobre costos desproporcionados de posibles soluciones propues-
tas durante la sesión. Sin este tipo de retroalimentación inmediata, pueden surgir soluciones irreales con costos
excesivos en la propuesta, que serán difíciles de descartar más adelante.
Puede elegir de ocho a doce usuarios de cualquier rango para que participen en las sesiones JAD. Trate de
seleccionar a los que puedan articular la información que necesitan para realizar sus trabajos, así como lo que
desean en un sistema de cómputo nuevo o mejorado.
El líder de la sesión no debe ser un experto en el análisis y diseño de sistemas, sino alguien con excelentes
habilidades de comunicación como para poder facilitar las interacciones apropiadas. Tenga en cuenta que no
le conviene usar un líder de sesión que se reporte con otra persona en el grupo. Para evitar que esto ocurra, tal
vez la organización esté de acuerdo en retener un consultor administrativo externo para que actúe como líder de
sesión. El objetivo es contar con alguien que pueda atraer la atención del grupo para tratar con las cuestiones
importantes de sistemas, negociar y resolver conflictos en forma satisfactoria y ayudar a que los miembros del
grupo lleguen a un consenso.
Su sesión JAD también debe incluir uno o dos observadores que sean analistas o expertos técnicos de otras
áreas funcionales para ofrecer explicaciones técnicas y consejos al grupo durante las sesiones. Además debe ha-
ber un escriba del departamento de sistemas de información en las sesiones JAD para escribir formalmente todo
lo que se haga.www.xlibros.com

112 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
E X P E R I E N C I A D E H Y P E R C A S E ® 4 . 1
“Bueno, le advertí que no siempre estaba todo tranquilo aquí en
MRE. Seguramente ya habrá conocido a muchos de nuestros em-
pleados clave y está empezando a comprender cómo son realmente
las cosas. ¿Quién hubiera pensado que unas inocentes decisiones
sobre sistemas, como en dónde comprar un COMTEX o Shiroma,
crearían tanta hostilidad? Bueno, vivir y aprender, es lo que siempre
digo. ¡Por lo menos ahora sabrá a lo que se enfrenta cuando tenga
que empezar a recomendar software y hardware!”.
“Es curioso: hay de preguntas a preguntas. Yo mismo estoy a
favor de las preguntas abiertas, pero cuando tengo que responderlas,
no siempre es fácil”.
Preguntas de HYPERCASE
1. Use las preguntas de entrevistas que se plantean en HyperCase
para dar cinco ejemplos de preguntas abiertas y cinco ejemplos de
preguntas cerradas. Explique por qué sus ejemplos se clasifican
correctamente como tipos de preguntas abiertas o cerradas.
2. Mencione tres preguntas de sondeo que sean parte de la
entrevista a Daniel Hill. En especial, ¿qué aprendió al dar
seguimiento a las preguntas que hizo a Daniel?
3. Mencione tres preguntas de sondeo que sean parte de la
entrevista a Snowden Evans. En especial, ¿qué aprendió al
dar seguimiento a las preguntas que hizo a Snowden?
FIGURA 4.HC1
Al colocar el puntero en una pregunta de HyperCase se revelará una respuesta.
Ubicación de las reuniones JAD
Le recomendamos que, de ser posible, realice las sesiones fuera del sitio con una duración de dos a cuatro días
fuera del sitio, lejos de la organización, en un ambiente cómodo. Algunos grupos utilizan centros ejecutivos o
incluso instalaciones de soporte de decisiones en grupo disponibles en las principales universidades. La idea es
minimizar las distracciones y responsabilidades diarias del trabajo regular de los participantes. La sala debe alo-
jar cómodamente a las personas invitadas. El equipo mínimo para apoyar la presentación incluye dos proyectores
(apropiados para los materiales a presentar: acetatos, presentaciones electrónicas, hojas impresas, etcétera), un
pizarrón blanco, un rotafolios y acceso a una copiadora. Las salas de soporte de decisiones en grupo también
proporcionan PC en red, un sistema de proyección y software escrito para facilitar la interacción en grupo, al
tiempo que se minimizan los comportamientos en grupo improductivos.
Programe su sesión JAD cuando todos los participantes se puedan comprometer a asistir. No lleve a cabo las
sesiones a menos que realmente puedan asistir todos los convocados. Esta regla es imprescindible para el éxito
de las sesiones. Asegúrese de que todos los participantes reciban una agenda antes de la reunión y considere lle-www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 113
var a cabo una reunión de orientación de medio día, cuando menos una semana antes del taller para que los que
estén involucrados sepan lo que se espera de ellos. Dicha reunión previa le permitirá avanzar con rapidez y actuar
con confianza una vez que se convoque la verdadera reunión.
Obtención de un análisis estructurado de las actividades del proyecto
IBM recomienda que las sesiones JAD examinen estos puntos en el proyecto de sistemas propuesto: planeación,
recepción, procesamiento/rastreo de recibos, monitoreo y asignación, procesamiento, registro, envío y evalua-
ción. Para cada tema también hay que formular y responder las preguntas quién, qué, cómo, dónde y por qué. En
definitiva, los sistemas interactivos ad hoc, como los sistemas de soporte de decisiones y otros tipos de sistemas
dependientes del estilo del encargado de tomar las decisiones (incluyendo los sistemas de prototipos), no se ana-
lizan con tanta facilidad con la metodología estructurada de JAD.
Como analista involucrado con las sesiones JAD, usted debe consultar las notas, que alguien designado tome
durante la reunión, para preparar un documento de especificaciones con base en lo que ocurrió en ella. Presente
en forma sistemática los objetivos de la administración, así como el alcance y los límites del proyecto. Incluya
también los aspectos específicos del sistema, como los detalles en pantalla y los esquemas de los informes.
Beneficios potenciales al usar JAD en vez de las entrevistas tradicionales
Existen cuatro beneficios potenciales que usted, los usuarios y su equipo de análisis de sistemas deben tener en con-
sideración al sopesar las posibilidades de usar el diseño de aplicación conjunta. El primer beneficio potencial es el
ahorro de tiempo en comparación con las entrevistas tradicionales cara a cara. Algunas organizaciones han estimado
que las sesiones JAD permiten ahorrar el 15 por ciento del tiempo en comparación con el método tradicional.
Además del ahorro en tiempo es posible efectuar un desarrollo rápido a través de JAD: como las entrevistas
a los usuarios no se llevan a cabo en forma serial durante un periodo de semanas o meses, el desarrollo puede
avanzar con mayor rapidez.
Un tercer beneficio a considerar es la posibilidad de mejorar la posesión del sistema de información. Como
analistas, nos esforzamos siempre en involucrar a los usuarios de manera significativa y los alentamos a que
tomen posesión de los sistemas diseñados lo antes posible. Debido a su naturaleza interactiva y alto grado de
visibilidad, JAD ayuda a los usuarios a que se involucren lo más pronto posible en los proyectos de sistemas y
considera seriamente su retroalimentación. La participación en una sesión JAD ayuda en un momento dado a re-
flejar las ideas del usuario en el diseño final.
Un beneficio final de participar en las sesiones JAD es el desarrollo creativo de los diseños. El carácter in-
teractivo de JAD tiene mucho en común con las técnicas de lluvias de ideas que generan nuevas propuestas y
combinaciones entre ellas, debido al entorno dinámico y estimulante. Los diseños pueden evolucionar a través de
interacciones facilitadas, en vez de hacerlo en un aislamiento relativo.
Desventajas potenciales de JAD
Hay tres desventajas u obstáculos que también debemos sopesar al decidir si usaremos las entrevistas conven-
cionales o JAD. La primera desventaja es que JAD requiere que todos los participantes comprometan mucho
tiempo. Como JAD requiere su dedicación durante un periodo de dos a cuatro días, no es posible realizar nin-
O P O R T U N I D A D D E C O N S U L T O R Í A 4 . 3
Analista de sistemas, supongo
“¿Sabe qué pienso del trabajo del último equipo de análisis de
sistemas? Los documentos impresos que crearon son una jungla.
Para averiguar el costo de la materia prima para nosotros, tengo que
abrirme paso a golpe de pluma por el exceso de datos. Voy tachando
todo lo irrelevante y algunas veces tengo que arrancar demasiada
maleza para llegar a las cifras que necesito”, dice Henry Stanley,
supervisor de contabilidad para Zenith Glass Company, mientras
apunta descontento hacia una desordenada pila de documentos im-
presos mutilados que brotan a un lado de su escritorio.
Identifique la metáfora primordial que utiliza Henry para des-
cribir los documentos impresos que recibe, además de la accesibili-
dad a la información en ellos. Describa en un párrafo cómo le puede
ayudar este paso a comprender la postura de Henry en relación con
cualquier trabajo propuesto por su equipo de análisis de sistemas.
En un párrafo, adopte la metáfora de Henry y extiéndala en un sen-
tido más positivo durante su entrevista con él.www.xlibros.com

114 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
guna otra actividad en forma concurrente ni postergar actividades, como se realiza comúnmente en las entrevistas
cara a cara.
El segundo obstáculo se produce cuando la preparación para las sesiones JAD es inadecuada en cualquier as-
pecto, o si el informe de seguimiento y la documentación de las especificaciones están incompletos. En estos ca-
sos, los diseños resultantes podrían ser insatisfactorios. Es necesaria la conjunción de muchas variables correctas
para que el JAD sea exitoso; en contraste, muchas cosas podrían salir mal. El éxito de los diseños que resultan de
las sesiones JAD es menos predecible que el que se logra mediante las entrevistas estándar.
Por último, tal vez las habilidades necesarias de la organización y su cultura no estén lo bastante desarrolla-
das como para permitir el esfuerzo concertado requerido para ser productivos en un entorno JAD. Al final tendrá
que juzgar si la organización realmente está comprometida y preparada para esta metodología.
USO DE CUESTIONARIOS
El uso de cuestionarios es una técnica de recopilación de información que permite a los analistas de sistemas
estudiar las posturas, las creencias, el comportamiento y las características de varias personas clave en la organi-
zación que se pueden ver afectadas por los sistemas actual y propuesto. Las posturas son lo que las personas en
la organización dicen desear (en un nuevo sistema, por ejemplo); las creencias son lo que las personas dan por
cierto; el comportamiento es lo que hacen los miembros de la organización, y las características son las propie-
dades de las personas u objetos.
Las respuestas obtenidas a través de cuestionarios (también conocidos como encuestas) en los que se utili-
zan preguntas cerradas se pueden cuantificar. Si encuesta personas a través del correo electrónico o Web, puede
usar software para convertir las respuestas electrónicas directamente en tablas de datos para analizarlas mediante
una aplicación de hoja de cálculo o paquetes de software estadísticos. Las respuestas a los cuestionarios en los
que se utilizan preguntas abiertas se analizan e interpretan de otras formas. Las respuestas a las preguntas sobre
posturas y creencias son sensibles a las palabras elegidas por el analista de sistemas.
Por medio del uso de cuestionarios, el analista puede buscar cuantificar lo que encontró en las entrevistas.
Además, es posible usar cuestionarios para determinar qué tan difundido o limitado está realmente un senti-
miento expresado en una de las entrevistas. Por lo contrario, se pueden utilizar cuestionarios para encuestar a una
muestra grande de usuarios de sistemas con el fin de detectar problemas o llevar a la mesa de discusión cuestio-
nes importantes antes de programar las entrevistas.
En este capítulo vamos a comparar y contrastar los cuestionarios con las entrevistas. Hay muchas similitudes
entre las dos técnicas y tal vez lo ideal sería utilizarlas en conjunto, ya sea para dar seguimiento a las respuestas
confusas de un cuestionario con una entrevista, o para diseñar el primero con base en lo que se descubrió en la
entrevista. Sin embargo, cada técnica tiene sus propias funciones específicas, por lo que no siempre es necesario
o conveniente utilizar ambas.
Planeación del uso de cuestionarios
A primera vista, tal vez los cuestionarios parezcan una forma rápida de recopilar cantidades masivas de datos
sobre la forma en que los usuarios valoran el sistema actual, los problemas que experimentan con su trabajo
y lo que las personas esperan de un sistema nuevo o modificado. Aunque es cierto que podemos recopilar
mucha información a través de los cuestionarios sin invertir tiempo en las entrevistas cara a cara, para de-
sarrollar un cuestionario útil se requiere mucho tiempo de planeación. Cuando decidimos encuestar a los
usuarios por correo electrónico o a través de Web, debemos tomar en cuenta ciertos aspectos de planeación
adicionales relacionados con la confidencialidad, la autenticación de la identidad y los problemas de respuestas
múltiples.
Primero hay que decidir lo que planeamos conseguir a través del uso de una encuesta. Por ejemplo, si desea
conocer el porcentaje de usuarios que prefieren una página FAQ para informarse sobre nuevos paquetes de
software, un cuestionario podría ser la técnica apropiada; si desea un análisis detallado del proceso de toma
de decisiones de un gerente, la entrevista es una mejor opción.
He aquí algunos lineamientos para ayudarlo a decidir si es apropiado utilizar cuestionarios. Considere el uso
de cuestionarios si:
1. Las personas a quienes necesita interrogar están esparcidas en un área amplia (distintas sucursales de la
misma corporación).
2. Hay gran cantidad de personas involucradas en el proyecto de sistemas, por lo que es importante saber qué
proporción de un grupo dado (por ejemplo, la gerencia) aprueba o desaprueba una característica específica
del sistema propuesto.
3. Piensa realizar un estudio exploratorio y desea medir la opinión general antes de que el proyecto de sistemas
tome cualquier dirección específica.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 115
4. Desea estar seguro de que se identifiquen y consideren los problemas con el sistema actual en las entrevistas
de seguimiento.
Una vez que haya determinado que tiene buenos motivos para usar un cuestionario y después de que haya
señalado los objetivos a cumplir por medio de éste, podrá empezar a formular las preguntas.
Escribir las preguntas
La mayor diferencia entre las preguntas que se utilizan en la mayoría de las entrevistas y las que se utilizan en
cuestionarios es que las entrevistas permiten la interacción entre las preguntas y sus significados. En una entre-
vista, el analista tiene la oportunidad de refinar una pregunta, definir un término confuso, cambiar el curso del
cuestionamiento, responder a una mirada desconcertada y en general, controlar el contexto.
En un cuestionario, muy pocas de estas oportunidades son posibles. Por lo tanto, para el analista las pregun-
tas deben ser tan claras como el agua, el flujo del cuestionario debe ser convincente, se debe anticipar a las pre-
guntas del encuestado, y la administración del cuestionario se debe planear con detalle (el encuestado es la persona
que responde o contesta el cuestionario).
Los tipos de preguntas básicas que se utilizan en el cuestionario son abiertas y cerradas, como vimos en las
entrevistas. Debido a las restricciones que se imponen en los cuestionarios, se justifica un análisis adicional sobre
los tipos de preguntas.
PREGUNTAS ABIERTAS Recuerde que las preguntas (o declaraciones) abiertas son las que dejan abiertas todas las
posibles opciones de respuesta para el encuestado. Por ejemplo, las preguntas abiertas en un cuestionario podrían
ser: “Describa los problemas que experimenta en la actualidad con los informes de las salidas”, o “En su opinión,
¿qué tan útiles son los manuales de usuario para la aplicación de contabilidad del sistema actual?”
Al escribir preguntas abiertas para un cuestionario, debemos anticiparnos al tipo de respuesta que obten-
dremos. Por ejemplo, si hace una pregunta como: “¿Cómo se siente en relación con el nuevo sistema?”, las res-
puestas pueden ser demasiado amplias como para obtener una interpretación o comparación precisa. Por lo tanto,
incluso cuando escriba una pregunta abierta, ésta debe ser lo suficientemente estrecha como para guiar a los
encuestados a responder en cierta forma específica (en la figura 4.10 hay ejemplos de preguntas abiertas).
En particular, las preguntas abiertas son adecuadas para las situaciones en las que queremos conocer las
opiniones de los miembros de la organización sobre cierto aspecto del sistema, ya sea un producto o un proceso.
En tales casos es conveniente utilizar preguntas abiertas cuando es imposible enlistar con efectividad todas las
posibles respuestas a la pregunta.
PREGUNTAS CERRADAS Recuerde que las preguntas (o declaraciones) cerradas son aquellas que limitan o cierran
las opciones de respuestas disponibles para el encuestado. Por ejemplo, en la figura 4.11 la declaración en la
pregunta 23 (“A continuación se muestran los seis paquetes de software disponibles en este momento. Marque
el (los) paquete(s) de software que utiliza personalmente con más frecuencia”) es cerrada. Observe que a los
encuestados no se les pregunta por qué prefieren el paquete, ni se les pide que seleccionen más de uno, incluso
aunque esa sea una respuesta más representativa.
Hay que utilizar preguntas cerradas cuando el analista de sistemas pueda enlistar de manera efectiva todas
las posibles respuestas a la pregunta y cuando todas éstas sean mutuamente exclusivas (al elegir una de ellas se
descarta la posibilidad de elegir cualquier otra).
Use preguntas cerradas cuando desee encuestar a una amplia muestra de personas. La razón se vuelve obvia
al momento de imaginar cómo se verán los datos que vamos a recolectar. Si utiliza sólo preguntas abiertas para
cientos de personas, sería imposible lograr un análisis e interpretación correctos de sus respuestas sin la ayuda de
un programa de análisis de contenido computarizado.
Elegir uno u otro tipo de preguntas implica sacrificar unas ventajas para lograr otras. La figura 4.12 sintetiza
la relación entre las ventajas de un tipo y la ventajas del otro. Tenga en cuenta que las respuestas a las preguntas
abiertas pueden ayudar a los analistas a obtener una visión detallada y preliminar, así como amplitud y profundi-
dad sobre un tema. Aunque las preguntas abiertas se pueden escribir con facilidad, las respuestas para ellas son
difíciles y se requiere tiempo para analizarlas.
Al referirnos a la escritura de preguntas cerradas con respuestas ordenadas o desordenadas, a menudo
nos referimos al proceso como escalar. En una sección posterior hablaremos sobre el uso de escalas en las
encuestas.
TERMINOLOGÍA DE LAS PREGUNTAS Al igual que en el caso de las entrevistas, el lenguaje de los cuestionarios
es un aspecto en extremo importante de su efectividad. Incluso si el analista de sistemas cuenta con un conjunto
estándar de preguntas relacionadas con el desarrollo de sistemas, es conveniente escribirlas de manera que
reflejen la terminología propia de la empresa.www.xlibros.com

116 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Los encuestados aprecian los esfuerzos de alguien que se molesta en escribir un cuestionario que refleje su
propio uso del lenguaje. Por ejemplo, si la empresa utiliza el término supervisores en vez de gerentes, o unidades
en vez de departamentos, al incorporar los términos preferidos al cuestionario los encuestados se relacionan me-
jor con el significado de las preguntas. Será más fácil interpretar las respuestas con precisión y los encuestados
serán más entusiastas en general.
Para verificar que el lenguaje utilizado en el cuestionario sea el de los encuestados, pruebe varias preguntas
de muestra en un grupo piloto (de prueba). Pídales que pongan especial atención en cuanto a la precisión de las
palabras y que cambien cualquier palabra que no suene adecuada.
He aquí algunos lineamientos que puede utilizar al elegir el lenguaje para su cuestionario:
1. Use el lenguaje de los encuestados siempre que sea posible. Mantenga un vocabulario simple.
2. Concéntrese en ser específico en vez de utilizar palabras imprecisas. Evite también las preguntas demasiado
específicas.
53. ¿Cuáles son los problemas más frecuentes que
experimenta con la salida de la computadora?
A.
B.
C.
54. De los problemas que enlistó en la pregunta anterior,
¿cuál es el más difícil de resolver?
55. ¿Por qué?
Las preguntas abiertas
pueden pedir al
encuestado que haga
listas...
... o respuestas
detalladas ...
... o respuestas
cortas.
A continuación hay preguntas sobre usted. Llene los espacios
en blanco lo mejor que pueda.
67. ¿Cuánto tiempo lleva trabajando para esta empresa?
años y meses
68. ¿Cuánto tiempo lleva trabajando en la misma industria?
años y meses
69. ¿En qué otras industrias ha trabajado?
FIGURA 4.10
Preguntas abiertas que se utilizan
para los cuestionarios.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 117
Responda a las preguntas 23 y 24 marcando la casilla apropiada.
23. A continuación se muestran los seis paquetes de software
disponibles en este momento. Marque el (los) paquete(s)
de software que utiliza personalmente con más frecuencia
[ ] Microsoft Excel [ ] Microsoft Access
[ ] Microsoft PowerPoint [ ] Microsoft Windows Live Mail
[ ] Oracle SCM [ ] Visible Analyst
24. “Por lo general las cifras de ventas están retrasadas".
[ ] De acuerdo [ ] En desacuerdo
Responda a las preguntas 25 y 26 encerrando en un círculo el número
apropiado.
25. “Cuando los servicios de datos de cómputo preparan las
cifras de ventas, se retrasan".
Nunca Raras veces A veces A menudo Siempre
1 2 3 4 5
Responda a las preguntas 45-48 encerrando en un círculo la
respuesta apropiada.
45. La división en la que me encuentro en la actualidad se llama
Inversiones
Operaciones
Marketing
46. Mis antecedentes académicos se pueden describir mejor
como
Preparatoria
Estudios universitarios parciales
Licenciatura
Maestría o superior
Mi género es
Masculino
Femenino
Las preguntas cerradas
pueden pedir al
encuestado que marque
una casilla ...
... o que encierre
un número ...
... o encerrar
toda la respuesta.
FIGURA 4.11
Las preguntas cerradas en los
cuestionarios ayudan a asegurar
las respuestas.
Abiertas Cerradas
Lento Rápido
Alto Bajo
Alto Bajo
Fácil Difícil
Difícil Fácil
Velocidad de llenado
Naturaleza exploratoria
Amplitud y profundidad
Facilidad de preparación
Facilidad de análisis
FIGURA 4.12
Las ventajas que sacrifica al elegir
uno y otro tipo de preguntas.www.xlibros.com

118 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
3. Trate de mantener las preguntas cortas.
4. No use un tono condescendiente, al usar opciones redactadas en lenguaje de bajo nivel, para dirigirse a los
encuestados.
5. Evite la predisposición en sus palabras. Esto también significa evitar preguntas censurables.
6. Dirija las preguntas a los encuestados apropiados (es decir, los que sean capaces de responder). No suponga
que conocen demasiado.
7. Asegúrese de que las preguntas sean correctas en el sentido técnico antes de incluirlas.
8. Use software para verificar si el nivel de lectura es apropiado para los encuestados.
Uso de escalas en los cuestionarios
Escalar es el proceso de asignar números u otros símbolos a un atributo o característica, con el fin de medirlos.
A menudo las escalas son arbitrarias y pueden no ser únicas. Por ejemplo, la temperatura se mide en varias for-
mas, por ejemplo, en escala Fahrenheit (en donde el agua se congela a 32 grados y hierve a 212 grados) y en
escala Celsius (en donde el congelamiento ocurre a 0 grados y el hervor a 100 grados).
MEDICIÓN Hay dos formas de escalas de medición que los analistas de sistemas utilizan por lo general:
1. Escalas nominales
2. Escalas de intervalo
Las escalas nominales se utilizan para clasificar cosas. Una pregunta tal como:
¿Qué tipo de software utiliza más?
1 Un procesador de palabras
2 Una hoja de cálculo
3 Una base de datos
4 Un programa de correo electrónico
utiliza una escala nominal. En definitiva, las escalas nominales son las formas más débiles de medición. Por lo
general, todo lo que el analista puede hacer con ellas es obtener los totales de cada clasificación.
Las escalas de intervalo poseen la característica de que los intervalos entre cada uno de los números son
iguales. Debido a ello, se pueden realizar operaciones matemáticas con los datos del cuestionario para obtener un
análisis más completo. Las escalas Fahrenheit y Celsius son ejemplos de escalas de intervalo, las cuales miden
la temperatura.
El ejemplo antes mencionado del Centro de información no es en definitiva el de una escala de intervalo,
pero si anclamos la escala en uno de sus extremos, tal vez el analista quiera suponer que el encuestado percibe
que los intervalos son iguales:
¿Qué tan útil es el soporte proporcionado por el Grupo de soporte técnico?
No es nada útil Extremadamente útil
1 2 3 4 5
Si el analista de sistemas hace esta suposición, es posible un análisis más cuantitativo.
VALIDEZ Y CONFIABILIDAD Al construir escalas podemos usar dos medidas de rendimiento: validez y
confiabilidad. El analista de sistemas debe estar consciente de estas dos cuestiones.
La validez es el grado con el que la pregunta mide lo que el analista requiere. Por ejemplo, si el propósito
del cuestionario es determinar si la organización está lista o no para un cambio importante en las operaciones de
cómputo, ¿los cuestionarios miden eso?
La confiabilidad implica consistencia. Si el cuestionario se aplicó una vez y después se volvió a aplicar bajo
las mismas condiciones, y se obtuvieron los mismos resultados en ambas ocasiones, se dice que el instrumento
tiene consistencia externa. Si el cuestionario contiene subpartes y éstas tienen resultados equivalentes, se dice
que el instrumento tiene consistencia interna. Es importante tener consistencia externa e interna.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 119
CONSTRUCCIÓN DE ESCALAS La construcción de escalas es una tarea seria. Si construye las escalas con poco
cuidado se producirá uno de los siguientes problemas:
1. Indulgencia.
2. Tendencia central.
3. Efecto halo.
La indulgencia es un problema que provocan los encuestados que califican en forma superficial. Para evitar
el problema de la indulgencia, el analista de sistemas puede desplazar la categoría “promedio” a la izquierda
(o derecha) del centro.
La tendencia central es un problema que ocurre cuando los encuestados califican todo como promedio. Para
mejorar la escala, el analista puede 1) hacer las diferencias más pequeñas en los dos extremos, 2) ajustar la soli-
dez de los descriptores o 3) crear una escala con más puntos.
El efecto halo es un problema que surge cuando la impresión que se forja en una pregunta se acarrea hasta
la siguiente. Por ejemplo, si va a calificar un empleado del que tiene una impresión favorable, tal vez le otorgue
una calificación alta en todas las categorías o rasgos, sin importar que sea o no realmente una de sus mejores ca-
racterísticas. La solución es colocar un rasgo y varios empleados en cada página, en vez de un empleado y varios
rasgos en una página.
Diseño de los cuestionarios
Muchos de los mismos principios relevantes para el diseño de formularios para introducir datos (como veremos
en el capítulo 12) también son importantes aquí. Aunque la intención del cuestionario es recopilar información
sobre posturas, creencias, comportamiento y características cuyo impacto pueda alterar el trabajo del usuario en
forma considerable, los encuestados no siempre se ven motivados a responder. Recuerde que los miembros de la
organización reciben demasiadas encuestas en general, muchas de las cuales son con frecuencia malintenciona-
das y triviales.
Un cuestionario bien diseñado y relevante puede ayudar a vencer parte de esta resistencia a responder. He
aquí algunas reglas para diseñar un buen cuestionario:
1. Incluya mucho espacio en blanco.
2. Incluya mucho espacio para escribir o teclear las respuestas.
3. Facilite a los encuestados la acción de marcar con claridad sus respuestas.
4. Mantenga un estilo consistente.
Al diseñar cuestionarios para Web, aplique las mismas reglas que utiliza al diseñar cuestionarios en papel.
La mayoría de los paquetes de software permiten insertar uno de los formatos de entrada de datos de uso común
que se muestran en la figura 4.13. Siga los cuatro lineamientos anteriores para obtener una mejor tasa de respues-
tas en el cuestionario.
Cuadro de texto
de una línea
Nombre PropósitoApariencia
Cuadro de texto
desplazable
Casilla de
verificación
Botón de
opción
Menú
desplegable
Botón
Se utiliza para obtener una pequeña cantidad de texto y
limitar la respuesta a unas cuantas palabras
Se utiliza para obtener uno o más párrafos de texto
Se utiliza para obtener una respuesta del tipo sí-no (por
ejemplo, ¿Desea que lo incluyamos en la lista de correo?)
Se utiliza para obtener una respuesta del tipo sí-no o
verdadero-falso
Se utiliza para obtener resultados más consistentes (el
encuestado puede elegir la respuesta apropiada de una
lista predeterminada; por ejemplo, una lista de abreviaturas
de estados)
Se utiliza con frecuencia para una acción (por ejemplo,
el encuestado hace clic en un botón marcado como
“Enviar” o “Borrar”)
FIGURA 4.13
Al diseñar una encuesta Web,
tenga en cuenta que hay distintas
maneras de capturar las respuestas.www.xlibros.com

120 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U L T O R Í A 4 . 4
El cuestionario insoportable
“Voy a entrar en depresión o, por lo menos, voy a estar desani-
mado si alguien no averigua esto pronto”, dice Penny Stox, ge-
rente de oficina para Carbon, Carbon & Rippy, una casa de bolsa
de tamaño considerable. Penny está sentada en una mesa de
conferencias frente a usted y dos de sus ejecutivos de cuenta más
productivos, By Lowe y Sal Hy. Todos están reflexionando sobre
las respuestas a un cuestionario que se distribuyó entre los eje-
cutivos de cuenta de la empresa, el cual se muestra en la figura
4.C1.
“Necesitamos una bola de cristal para entenderlos”, dicen By
y Sal al mismo tiempo.
“Tal vez refleje cierto tipo de ciclo optimista, o algo así”, dice
Penny al tiempo que lee más respuestas. “Por cierto, ¿quién diseñó
esta joya?”
“Rich Kleintz”, dicen By y Sal al unísono.
“Bueno, como pueden ver, ¡no nos dice nada!”, exclama Penny.
Penny y su personal están insatisfechos con las respuestas que
recibieron en el cuestionario insoportable; además sienten que las
respuestas son reflexiones poco realistas de la cantidad de informa-
ción que desean los ejecutivos de cuenta. Explique en un párrafo por
qué están ocurriendo estos problemas. En una hoja aparte, cambie
la escala de las preguntas para evitar estos problemas.
Circule el número apropiado para cada fuente de información descrita.
1. Informes industriales Aproximadamente
igualMenos Más
1 2 3 4 5
2. Análisis de tendencias
Aproximadamente
igualMenos Más
1 2 3 4 5
3. Gráficos generados por computadora
Aproximadamente
igualMenos Más
1 2 3 4 5
4. Servicios de asesoría en inversiones
Aproximadamente
igualMenos Más
1 2 3 4 5
5. Gráficos de puntos y figuras
Aproximadamente
igualMenos Más
1 2 3 4 5
6. Análisis de cartera de clientes computarizada
Aproximadamente
igualMenos Más
1 2 3 4 5
7. Información actualizada
Aproximadamente
igualMenos Más
1 2 3 4 5
Necesitamos
cambiar este
cuestionario.
FIGURA 4.C1
Cuestionario desarrollado para la casa de bolsa Carbon, Carbon & Rippy, por Rich Kleintz.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 121
ORDEN DE LAS PREGUNTAS No existe una forma de ordenar las preguntas en el cuestionario que sea la mejor
de todas. Una vez más, al ordenar preguntas debe tener en cuenta sus objetivos al usar el cuestionario y después
determinar la función de cada pregunta para ayudarle a obtener sus objetivos. También es importante ver el
cuestionario a través de los ojos del encuestado. Algunos lineamientos para ordenar preguntas son:
1. Coloque primero las preguntas que sean importantes para los encuestados.
2. Agrupe elementos de contenido similar.
3. Introduzca primero las preguntas menos controversiales.
Es conveniente que los encuestados no se sientan amenazados y que se interesen en las preguntas lo más que se
pueda, sin que se alteren por alguna cuestión específica.
O P O R T U N I D A D D E C O N S U L T O R Í A 4 . 5
Orden en las cortes
“Me encanta mi trabajo”, dice Tennys para empezar la entrevista
con una volea. “Es muy parecido a un juego. Mantengo mi vista en
la pelota y nunca me distraigo”, continúa. Tennyson “Tennys” Courts
es gerente de Global Health Spas, Inc., una empresa que cuenta con
spas medicinales y recreativos populares en todo el mundo.
“Ahora que terminé mi MBA, siento que estoy en la cima del
mundo con Global”, dice Tennys. “Creo que realmente puedo ayu-
dar a poner en forma este negocio con sus computadoras y spas
medicinales”.
Tennys está tratando de ayudarle a usted y a su grupo de siste-
mas, que están desarrollando un sistema para que lo utilicen las 80
sucursales (en donde en la actualidad cada grupo administra su
propio papeleo). “¿Le puedo pasar esto?”, Tennys pregunta a Terri
Towell, miembro del equipo de analistas de sistemas que usted di-
rige. “Es un cuestionario que diseñé para distribuirlo a todos los
gerentes de los spas”.
Terri, que siempre ha sido buena deportista, le dice a Tennys
que le encantaría dar un vistazo al formulario. Pero de vuelta en la
oficina, Terri le devuelve la pelota. Critique de manera sistemática
la técnica de Tennys según lo descrito en la figura 4.C2 y explíquele
punto por punto lo que necesita para ser un cuestionario sin igual
con un formulario ganador. Con base en la crítica que elabore, diga
a Tennys lo que debe hacer para volver a escribir el formulario, esta
vez en forma de encuesta Web.
CUESTIONARIO PARA TODOS LOS GERENTES DE SPAS MEDICINALES
*** URGENTE *** LLENE EL CUESTIONARIO DE INMEDIATO Y
ENTRÉGUELO EN PERSONA A SU GERENTE DE DIVISIÓN. SE RETENDRÁ
SU SIGUIENTE NÓMINA HASTA QUE SE CONFIRME QUE LO ENTREGÓ.
En 10 palabras o menos, ¿qué quejas ha presentado en relación con el
sistema de cómputo actual durante el periodo de los últimos seis meses
a un año?
¿Hay otras personas que se sientan igual que usted en su sucursal?
¿Quiénes? Haga una lista de sus nombres y puestos.
1. 2.
3. 4.
5.
7.
¿Cuál es el mayor problema que tiene al comunicar sus
requerimientos de información a las oficinas generales?
Descríbalo en forma breve.
¿Cuánto tiempo de inactividad en las computadoras
experimentó el año pasado?
1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 -
¿Hay equipo de cómputo que nunca utiliza?
Descripción Número de serie
¿Desea que se lo lleven? De acuerdo Neutral En desacuerdo
En su opinión, ¿qué hay que hacer ahora en cuanto a las
computadoras y Global Health Spas?
Gracias por llenar este cuestionario. • • • • • • • • • • • • • • • •
Terri
Por favor ayúdeme
a mejorar este
formulario.
Tennys
FIGURA 4.C2
Cuestionario desarrollado para los gerentes de Global Health Spas, por Tennys Courts.www.xlibros.com

122 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Administración de los cuestionarios
ENCUESTADOS El proceso de decidir quién recibirá el cuestionario se lleva a cabo en conjunto con la tarea de establecer
objetivos para sus resultados. El muestreo (que veremos en el capítulo 5) ayuda al analista de sistemas a determinar
el tipo de representación necesario y, en consecuencia, el tipo de encuestados que deben recibir el cuestionario.
A menudo se eligen encuestados que sean representativos debido a su rango, el tiempo que han estado con
la empresa, sus responsabilidades laborales o el interés especial en el sistema actual o propuesto. Asegúrese de
incluir suficientes encuestados para obtener un muestreo razonable en caso de que no se devuelvan algunos cues-
tionarios o de que algunas hojas de respuesta se llenen de manera incorrecta y por ende haya que descartarlas.
MÉTODOS PARA ADMINISTRAR EL CUESTIONARIO El analista de sistemas cuenta con varias opciones para
administrar el cuestionario; a menudo la elección del método administrativo se determina en base a la situación
de negocios existente. Las opciones para administrar el cuestionario son:
1. Convocar al mismo tiempo a todos los encuestados concernientes.
2. Entregar cuestionarios en blanco en forma personal y recoger los cuestionarios que ya estén llenos.
3. Permitir que los encuestados administren su propio cuestionario en el trabajo y lo depositen en una caja
ubicada en un lugar céntrico.
4. Enviar por correo los cuestionarios a los empleados en las sucursales y proveer una fecha de entrega,
instrucciones y un sobre con franqueo pagado.
5. Administrar el cuestionario en forma electrónica, ya sea a través de correo electrónico o Web.
Cada uno de estos cinco métodos tiene ventajas y desventajas. Es común permitir que los encuestados ad-
ministren su propio cuestionario. Las tasas de respuesta con este método son un poco más bajas que con los
otros métodos, debido a que las personas a veces se olvidan del formulario, lo pierden o lo ignoran de manera
intencional. Sin embargo, al administrar su propio cuestionario, las personas sienten que tienen asegurado su
anonimato y es posible que algunos encuestados den respuestas menos cautelosas. Las encuestas por correo elec-
trónico y Web se encuentran en la categoría de cuestionarios autoadministrados.
Administrar el cuestionario vía electrónica, ya sea por correo electrónico o a través de un sitio Web, es una
manera de llegar rápidamente a los usuarios del sistema actual. Se minimizan los costos de tener que sacar copias.
Además, el encuestado puede responder a su propia conveniencia para después recolectar todos los cuestionarios
en forma automática y almacenarlos en medios electrónicos. Hay cierto software que permite a los encuestados
empezar a contestar una encuesta, guardar sus respuestas y regresar más tarde para terminar de contestar en caso
de interrupciones. Se pueden enviar recordatorios a los encuestados de una manera fácil y económica por me-
dio de correo electrónico, al igual que las notificaciones para hacer saber al analista cuando el encuestado haya
abierto el correo electrónico. También hay software que convierte los datos de los correos electrónicos en tablas
para usarlas en software de hojas de cálculo o de análisis estadístico. Hay un servicio popular que los consultores
utilizan para crear y administrar encuestas en línea. SurveyMonkey.com (www.surveymonkey.com) es una em-
presa ubicada en Portland, Oregon que empezó en 1999 y hace poco agregó a sus ofrecimientos de productos un
servicio de marketing por email conocido como MailChimp.
La investigación muestra que los encuestados están dispuestos a responder, a través de Internet, preguntas
sobre cuestiones delicadas. Por ende, es probable que las preguntas que tal vez sean difíciles de plantear en per-
sona en relación con los problemas de sistemas, sí se puedan plantear en una encuesta Web.
Este capítulo aborda tres de los métodos interactivos clave
para recopilar información y que el analista de sistemas puede
utilizar: entrevistas, JAD y cuestionarios. Durante el proceso de
la entrevista, los analistas esperan escuchar cuestiones de HCI
relacionadas con la ergonomía, la estética, la capacidad de uso
y la utilidad, así como los objetivos, sentimientos, opiniones y
procedimientos informales en las entrevistas con los encarga-
dos de tomar las decisiones en la organización. Las entrevistas
son diálogos planeados de preguntas y respuestas entre dos
personas. Los analistas utilizan la entrevista para desarrollar
su relación con un cliente, observar el entorno de trabajo y
recolectar datos. Es preferible llevar a cabo las entrevistas en
persona.
Los cinco pasos a seguir para planear la entrevista son leer
el material sobre los antecedentes, establecer los objetivos de
la entrevista, decidir a quiénes entrevistar, preparar al entrevis-
tado y decidir sobre los tipos y la estructura de las preguntas.
Las preguntas son de dos tipos básicos: abiertas o cerradas.
Las preguntas abiertas permiten todas las opciones de respuesta
para el entrevistado. Las preguntas cerradas limitan las posibles
opciones de respuesta. Las preguntas de sondeo o de seguimiento
pueden ser cerradas o abiertas, pero le piden al entrevistado una
contestación más detallada.
Las entrevistas se pueden estructurar en tres formas: pirá-
mide, embudo o diamante. Las estructuras de pirámide empiezan
con preguntas cerradas detalladas y se amplían con preguntas
más generalizadas. Las estructuras de embudo empiezan con
preguntas abiertas generales y después se restringen a preguntas
cerradas más específicas. Las estructuras en forma de diamante
combinan las ventajas de las otras dos estructuras, pero se requiere
RESUMENwww.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 123
E X P E R I E N C I A D E H Y P E R C A S E ® 4 . 2
“ Tal vez ya se haya dado cuenta de que no todos disfrutan de
llenar cuestionarios en MRE. Al parecer recibimos más cuestiona-
rios que la mayoría de las empresas. Creo que es porque muchos de
los empleados, en especial los de la Unidad de capacitación ante-
rior, valoran las contribuciones de los datos de los cuestionarios en
nuestro trabajo con los clientes. Cuando examine el cuestionario
que distribuyó Snowden, tal vez no sólo quiera ver los resultados
sino también criticar los métodos. Siempre he pensado que real-
mente podemos mejorar nuestro rendimiento interno para, en un
momento dado, atender mejor a nuestros clientes. La próxima vez
que construyamos un cuestionario queremos ser capaces de mejorar
tres cosas: la confiabilidad de los datos, la validez de los datos y la
tasa de respuestas que recibimos”.
Preguntas de HYPERCASE
1. ¿Qué evidencia de cuestionarios ha encontrado en MRE? Sea
específico sobre lo que encontró y dónde lo hizo.
2. Critique el cuestionario que Snowden hizo circular. ¿Qué se
puede hacer para mejorar su confiabilidad, validez y tasa de
respuesta? Mencione tres sugerencias prácticas.
3. Escriba un cuestionario corto para dar seguimiento a algunos
aspectos de la fusión entre los departamentos de Sistemas
administrativos y la Unidad de capacitación en MRE que
todavía le intriguen. Asegúrese de observar todos los
lineamientos para el buen diseño de cuestionarios.
4. Rediseñe el cuestionario que escribió en la pregunta 3, de
forma que se pueda utilizar en una encuesta Web.
PALABRAS Y FRASES CLAVE
confiabilidad
cuestionario
diseño de aplicación conjunta (JAD)
efecto halo
encuestados
escala de intervalo
escala nominal
estructura de embudo
estructura de pirámide
estructura en forma de diamante
indulgencia
interacción humano-computadora (HCI)
objetivos del entrevistado
opiniones del entrevistado
preguntas abiertas
preguntas cerradas
preguntas cerradas bipolares
procedimientos informales
sentimientos del entrevistado
sondeos
tendencia central
validez
más tiempo para llevarlas a cabo. Hay concesiones implicadas al
decidir la estructura para hacer las preguntas de las entrevistas y
las secuencias de esas preguntas.
Para reducir tanto el tiempo como el costo de las entrevis-
tas personales, tal vez los analistas quieran considerar el diseño
de aplicaciones conjuntas (JAD) como alternativa. Mediante
el uso de JAD los analistas pueden analizar los requerimientos
humanos de información y diseñar una interfaz de usuario con
los usuarios en un ambiente de grupo. Una evaluación cuida-
dosa de la cultura específica de la organización ayudará al ana-
lista a juzgar si es adecuado usar JAD.
Mediante el uso de cuestionarios (encuestas), los analistas
de sistemas pueden recopilar datos sobre cuestiones de HCI,
posturas, creencias, comportamiento y características de las
personas clave en la organización. Las encuestas son útiles si
las personas en la organización están dispersas en una zona
amplia, si hay muchas personas involucradas con el proyecto
de sistemas, si se requiere un trabajo exploratorio antes de re-
comendar alternativas o si existe la necesidad de detectar pro-
blemas antes de llevar a cabo las entrevistas.
Una vez que se establecen los objetivos para la encuesta, el
analista puede empezar a escribir preguntas abiertas o cerradas.
Lo ideal sería que las preguntas fueran simples, específicas,
cortas, sin predisposiciones ni condescendencias, con precisión
técnica, dirigidas a personas que tengan conocimientos apro-
piados y escritas en un nivel de lectura apropiado. Tal vez el
analista de sistemas quiera usar escalas, ya sea para medir las
posturas o características de los encuestados o hacer que éstos
actúen como jueces en relación con el tema del cuestionario.
Escalar es el proceso de asignar números u otros símbolos a un
atributo o característica.
El control consistente del formato y estilo de los cuestiona-
rios puede producir una mejor tasa de respuesta. Podemos dise-
ñar las encuestas Web para fomentar respuestas consistentes.
Además, es importante ordenar y agrupar las preguntas de una
forma significativa para ayudar a los encuestados a entender el
cuestionario. Se pueden administrar las encuestas de varias for-
mas; por ejemplo vía electrónica a través del correo electrónico
o Web, o estando el analista presente entre un grupo de usua-
rios.www.xlibros.com

124 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
PREGUNTAS DE REPASO
1. ¿Qué tipos de información hay que buscar en las entrevistas?
2. Liste los cinco pasos necesarios en la preparación para una entrevista.
3. Defina lo que significa preguntas abiertas en una entrevista. Mencione ocho beneficios y cinco desventajas de usarlas.
4. ¿Cuándo es apropiado usar preguntas abiertas en las entrevistas?
5. Defina lo que implica el uso de preguntas cerradas en una entrevista. Mencione seis beneficios y cuatro desventajas de
usarlas.
6. ¿Cuándo es apropiado usar preguntas cerradas en las entrevistas?
7. ¿Qué es una pregunta de sondeo? ¿Cuál es el propósito de usar una pregunta de sondeo en las entrevistas?
8. Defina lo que significa estructura de pirámide. ¿Cuándo es útil emplearla en las entrevistas?
9. Defina lo que significa estructura de embudo. ¿Cuándo es útil emplearla en las entrevistas?
10. Defina lo que significa estructura en forma de diamante. ¿Cuándo es útil emplearla en las entrevistas?
11. Defina diseño de aplicación conjunta (JAD).
12. Haga una lista de las situaciones que garantizan el uso de JAD en vez de las entrevistas personales en la organización.
13. Haga una lista de los beneficios potenciales de usar el diseño de aplicación conjunta.
14. Haga una lista de tres posibles desventajas de usar JAD como alternativa para las entrevistas personales.
15. ¿Qué tipos de información busca el analista de sistemas mediante el uso de cuestionarios o encuestas?
16. Haga una lista de cuatro situaciones en las que se utilicen los cuestionarios en forma apropiada.
17. ¿Cuáles son los dos tipos básicos de preguntas que se utilizan en los cuestionarios?
18. Haga una lista de dos razones por las que un analista de sistemas usaría una pregunta cerrada en un cuestionario.
19. Haga una lista de dos razones por las que un analista de sistemas usaría una pregunta abierta en un cuestionario.
20. ¿Cuáles son los siete lineamientos para elegir el lenguaje para el cuestionario?
21. Defina lo que significa escalar.
22. ¿Cuáles son los dos tipos de información o de escalas que utilizan los analistas de sistemas con más frecuencia?
23. ¿Para qué se utilizan las escalas nominales?
24. Mencione un ejemplo de una escala de intervalo.
25. ¿Cuándo debe el analista usar escalas de intervalo?
26. Defina confiabilidad en relación con la construcción de escalas.
27. Defina validez en relación con la construcción de escalas.
28. Haga una lista de tres problemas que pueden ocurrir debido a la acción de construir escalas sin cuidado.
29. ¿Cuáles son las cuatro acciones que se pueden tomar para asegurar que el formato del cuestionario produzca una buena
tasa de respuesta?
30. ¿Qué preguntas hay que colocar primero en el cuestionario?
31. ¿Por qué hay que agrupar preguntas sobre temas similares?
32. ¿Cuál sería una ubicación apropiada para las preguntas controversiales?
33. Haga una lista de cinco métodos para administrar el cuestionario.
34. ¿Qué consideraciones son necesarias cuando los cuestionarios están basados en Web?
PROBLEMAS
1. Como parte de su proyecto de análisis para actualizar las funciones de contabilidad automatizadas para Xanadu
Corporation, una empresa fabricante de cámaras digitales, usted entrevistará a Leo Blum, el jefe de contabilidad. Escriba
de cuatro a seis objetivos de la entrevista relacionados con la forma en que Leo utiliza las fuentes de información, los
formatos de la información, la frecuencia con que toma decisiones, las calidades deseadas de información y el estilo de
toma de decisiones.
a. Escriba en un párrafo cómo se acercará a Leo para programar una entrevista.
b. Indique la estructura que elegirá para esta entrevista. ¿Por qué?
c. Leo tiene cuatro subordinados a su cargo que también utilizan el sistema. ¿Los entrevistaría también? ¿Sí o no, y
por qué?
d. ¿Trataría usted también de entrevistar clientes (visitantes del sitio Web)? ¿Hay mejores formas de obtener las
opiniones de los clientes? ¿Sí o no, y por qué?
e. Escriba tres preguntas abiertas que enviará por correo electrónico a Leo antes de su entrevista. Escriba un enunciado
en el que le explique por qué es preferible realizar una entrevista en persona, en vez de hacerlo por correo
electrónico.
2. He aquí cinco preguntas escritas por uno de los miembros de su equipo de análisis de sistemas. La persona a la que va a
entrevistar es el gerente local de LOWCO, un punto de venta de una cadena nacional de descuento, quien le ha pedido
que trabaje en un sistema de información de administración para proveer información sobre el inventario. Revise estas
preguntas para el miembro de su equipo.
1. ¿Cuándo fue la última vez que pensó seriamente en su proceso de toma de decisiones?
2. ¿Quiénes son los empleados problemáticos en su tienda? Es decir, los que mostrarán más resistencia a los cambios
en el sistema que propuse.
3. ¿Hay decisiones sobre las que necesite más información para tomarlas?
4. No tiene problemas graves con el sistema de control de inventario actual, ¿o sí?www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 125
5. Cuénteme un poco sobre los resultados que le gustaría ver.
a. Vuelva a escribir cada pregunta para que sea más efectiva al obtener información.
b. Ordene sus preguntas en estructura de pirámide, embudo o forma de diamante y etiquételas con el nombre de la
estructura que utilizó.
c. ¿Qué lineamientos puede dar al miembro de su equipo para mejorar sus preguntas de entrevistas en el futuro?
Elabore una lista.
3. Desde que usted entró, su entrevistado, Max Hugo, ha estado revolviendo papeles, mirando su reloj y golpeteando el
escritorio con sus dedos. Con base en lo que usted sabe sobre las entrevistas, adivina que Max está nervioso debido al
trabajo que tiene pendiente. Describa en un párrafo cómo lidiaría con esta situación, de manera que Max pudiera poner
toda su atención en la entrevista (no puede reprogramar la entrevista para otro día).
4. Escriba una serie de seis preguntas cerradas que traten sobre el tema del estilo de toma de decisiones para el gerente que
se describe en el problema 2.
5. Escriba una serie de seis preguntas abiertas que traten sobre el tema del estilo de toma de decisiones para el gerente que
se describe en el problema 2.
6. Examine la estructura de la entrevista que se presenta en la secuencia de las siguientes preguntas:
1. ¿Cuánto tiempo ha estado en este puesto?
2. ¿Cuáles son sus responsabilidades clave?
3. ¿Qué informes recibe?
4. ¿Cómo ve usted los objetivos de su departamento?
5. ¿Cómo describiría su proceso de toma de decisiones?
6. ¿Cómo se puede ofrecer un mejor soporte para ese proceso?
7. ¿Con qué frecuencia toma esas decisiones?
8. ¿A quién consulta cuando toma una decisión?
9. ¿Cuál es la decisión que usted toma y que es esencial para el funcionamiento del departamento?
a. ¿Qué estructura se utiliza? ¿Cómo puede saber?
b. Reestructure la entrevista; cambie la secuencia de las preguntas (puede omitir algunas si es necesario). Etiquete
las preguntas reordenadas con el nombre de la estructura que utilizó.
7. A continuación le mostramos el primer informe de una entrevista presentado por uno de los miembros de su equipo de
análisis de sistemas: “En mi opinión, la entrevista salió muy bien. El sujeto me dejó hablar con él durante una hora y
media. Me contó toda la historia sobre la empresa, que fue muy interesante. También mencionó que las cosas no han
cambiado tanto desde que empezó a trabajar en la empresa, hace aproximadamente 16 años. Nos reuniremos pronto otra
vez para terminar la entrevista, porque no tuvimos tiempo de ver las preguntas que preparé”.
a. Critique en dos párrafos el informe de la entrevista. ¿Qué información crítica falta?
b. ¿Qué información es superflua para el informe de la entrevista?
c. Si lo que se informa es lo que realmente ocurrió, ¿tiene usted tres sugerencias para ayudar a su compañero de equipo
a realizar una mejor entrevista la próxima vez?
8. Cab Wheeler es un analista de sistemas recién contratado para trabajar en su grupo. Cab siempre ha sentido que los
cuestionarios son un desperdicio. Ahora que usted debe realizar un proyecto de sistemas para MegaTrucks, Inc., una
empresa de transporte nacional con sucursales y empleados en 130 ciudades, desea utilizar un cuestionario para obtener
algunas opiniones sobre los sistemas actual y propuesto.
a. Con base en lo que usted sabe sobre Cab y MegaTrucks, mencione tres razones convincentes de por qué debería usar
una encuesta para este estudio.
b. Dados los meticulosos argumentos con los que usted cuenta, Cab está de acuerdo en usar un cuestionario pero
solicita enérgicamente que todas las preguntas sean abiertas para no obligar a los encuestados. En un párrafo,
persuada a Cab de que también son útiles las preguntas cerradas. Asegúrese de señalar las concesiones involucradas
con cada tipo de pregunta.
9. “Cada vez que llegan consultores aquí, reparten cuestionarios ridículos que no significan nada para nosotros. ¿Por qué
no se molestan en personalizarlo, aunque sea un poco?”, pregunta Ray Dient, jefe de sistemas de emergencia. Usted está
discutiendo sobre la posibilidad de empezar un proyecto de sistemas con la empresa Pohattan Power Company (PPC) de
Far Meltway, New Jersey.
a. ¿Qué pasos seguirá para personalizar un cuestionario estandarizado?
b. ¿Cuáles son las ventajas de adaptar un cuestionario para una organización específica? ¿Cuáles son las desventajas?
10. La siguiente es una pregunta de ejemplo en el borrador del cuestionario de Pohattan Power Company:
He estado con la empresa:
20 años a la fecha
10-15 años a la fecha
5-10 años a la fecha
menos de un año
Marque la que se adapte mejor a su situación.www.xlibros.com

126 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
a. ¿Qué tipo de escala utiliza el autor de la pregunta?
b. ¿Qué errores se cometieron al construir la pregunta y cuáles podrían ser las posibles respuestas?
c. Reformule la pregunta para obtener resultados más claros.
d. ¿En dónde debe aparecer la pregunta que escribió en el cuestionario?
11. En el cuestionario de PPC también se incluye esta pregunta:
Cuando llaman los clientes residenciales, siempre los guío hacia nuestro sitio Web para que obtengan una respuesta.
Algunas veces Nunca Siempre Por lo general
1 2 3 4
a. ¿Qué tipo de escala se supone que utiliza?
b. Reformule la pregunta y las posibles respuestas para obtener mejores resultados.
12. La figura 4.EX1 es un cuestionario diseñado por un empleado de Green Toe Textiles, una empresa que se especializa en la
fabricación de calcetines para caballeros. Di Wooly escribió el cuestionario debido a que, como gerente de las oficinas
generales en Juniper, Tennessee, le preocupa la compra e implementación propuesta de un nuevo sistema computacional.
Hola a todos los empleados
¿Qué hay de nuevo? Según lo que escuché, estamos pensando comprar una nueva computadora.
He aquí algunas preguntas que me gustaría que considerara cada uno de ustedes.
a. ¿Cuánto tiempo ha utilizado la computadora anterior?
b. ¿Con qué frecuencia se inhibe?
c. ¿Quién la repara por usted?
d. ¿Cuándo fue la última vez que sugirió una mejora al sistema de cómputo que se haya
empezado a usar? ¿Qué sugirió?
e. ¿Cuándo fue la última vez que sugirió una mejora al sistema de cómputo que nunca se
haya utilizado? ¿Qué sugirió?
f. ¿Usa una VDT, una impresora o ambas?
g. ¿Qué tan rápido puede teclear?
h. ¿Cuántas personas necesitan acceso a la base de datos con regularidad en su sucursal?
¿Hay alguien que no esté utilizando la computadora ahora y que quisiera hacerlo?
FIGURA 4.EX1
Cuestionario desarrollado por Di
Wooly.
a. Elabore una crítica en un enunciado para cada una de las preguntas anteriores.
b. Critique en un párrafo la distribución y el estilo en términos del espacio en blanco utilizado, el espacio para las
respuestas, la facilidad de responder, etcétera.
13. Con base en las conjeturas que usted obtuvo, la Srta. Wooly intenta comprender el cuestionario, reformular y ordenar las
preguntas (use preguntas abiertas y cerradas) de manera que sigan las buenas prácticas y produzcan información útil para
los analistas de sistemas. Indique en seguida de cada pregunta que escriba si es abierta o cerrada; además escriba un
enunciado en el que indique por qué escribió la pregunta de esa manera.
14. Rediseñe el cuestionario que creó para la Srta. Wooly en el problema 13 para usarlo en correo electrónico. Escriba un
párrafo en el que diga qué cambios se necesitaron para ajustarse a los usuarios de correo electrónico.
15. Rediseñe el cuestionario que creó para la Srta. Wooly en el problema 13 como una encuesta Web. Escriba un párrafo en
el que diga qué cambios se necesitaron para ajustarse a los usuarios Web.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 127
PROYECTOS EN GRUPO
1. Con los miembros de su grupo haga una pequeña representación de una serie de entrevistas con varios usuarios de
sistemas en Maverick Transport. Cada miembro de su grupo deberá elegir uno de los siguientes roles: presidente de la
empresa, director de tecnología de la información, despachador, agente de servicio al cliente o conductor de camión. Los
miembros del grupo que desempeñen roles de empleados de Maverick Transport deben tratar de describir con brevedad
sus responsabilidades, objetivos y necesidades de información en su trabajo.
El resto de los miembros del grupo deben desempeñar los roles de analistas de sistemas e idear preguntas de
entrevistas para cada empleado. Si hay suficientes personas en su grupo, a cada analista se le puede asignar la entrevista
de un empleado distinto. Los que desempeñen los roles de analistas de sistemas deben trabajar juntos para desarrollar
preguntas comunes, así como preguntas dirigidas a cada empleado individual. Asegúrese de incluir preguntas abiertas,
cerradas y de sondeo en sus entrevistas.
Maverick Transport trata de cambiar su tecnología obsoleta y poco confiable por una tecnología más reciente y
confiable. La empresa busca migrar de las terminales tontas conectadas a un equipo mainframe, ya que desea usar PC
de alguna forma y también le interesa investigar un sistema de satélite para rastrear los fletes y los conductores. Además
la empresa está interesada en buscar formas de reducir los inmensos requerimientos de almacenamiento y mejorar el
acceso a los problemáticos formularios de varias hojas escritos a mano que se incluyen en cada envío.
2. Lleve a cabo las cinco entrevistas en un ejercicio de juegos de rol. Si hay más de 10 personas en su grupo, permita que
dos o más analistas hagan las preguntas.
3. Escriba con su grupo un plan para una sesión JAD que sustituya a las entrevistas personales. Incluya los participantes
relevantes, el ambiente sugerido, etcétera.
4. Use los datos de las entrevistas que obtuvo del ejercicio en grupo del proyecto 1 sobre Maverick Transport para reunirse
con su grupo y transformar el diseño de un cuestionario para los cientos de conductores de camiones que trabajan para
Maverick Transport. Recuerde que a Maverick le interesa implementar un sistema de satélite para rastrear los fletes y los
conductores. Hay otros sistemas que podrían afectar a los conductores también. A medida que su grupo construya el
cuestionario, considere el nivel de educación que pueda tener el conductor y cualquier restricción de tiempo que le
impida completar dicho formulario.
5. Use los datos de las entrevistas que obtuvo del ejercicio en grupo del proyecto 1 sobre Maverick Transport para reunirse
con su grupo y diseñar un cuestionario Web o de correo electrónico para encuestar a los 20 programadores de la empresa
(15 de los cuales se contrataron el año pasado) sobre sus habilidades, ideas para sistemas nuevos o mejorados, etcétera.
Investigue las opciones de encuestas Web disponibles en SurveyMonkey.com. A medida que su grupo construya la
encuesta para los programadores, considere lo que aprendió sobre los usuarios en las otras entrevistas, así como la visión
que tiene el director de tecnología de la información con respecto a la empresa.
BIBLIOGRAFÍA SELECCIONADA
Ackroyd, S. y J. A. Hughes. Data Collection Context, 2da. edición. Nueva York: Addison-Wesley, 1992.
Cash, C. J. y W. B. Stewart, Jr. Interviewing Principles and Practices, 12va. edición. Nueva York: McGrawHill/Irwin, 2007.
Cooper, D. R. y P. S. Schindler. Business Research Methods, 10a. edición. Nueva York: McGrawHill/Irwin, 2007.
Deetz, S. Transforming Communication, Transforming Business: Building Responsive and Responsible Workplaces. Cresskill,
NJ: Hampton Press, 1995.
Emerick, D., K. Round y S. Joyce. Exploring Web Marketing and Project Management. Upper Saddle River, NJ: Prentice Hall
PTR, 2000.
Gane, C. Rapid System Development, Nueva York: Rapid System Development, 1987.
Georgia Tech’s Graphic, Visualization, and Usability Center. “GVU WWW Survey through 1998”. Disponible en: http://www.
cc.gatech.edu/gvu/user_surveys/survey-1998-10/. Último acceso: 15 de julio de 2009.
Hessler, R. M. Social Research Methods. Nueva York: West, 1992.
Joint Application Design. GUIDE Publication GPP-147. Chicago: GUIDE International, 1986.
Peterson, R. A. Constructing Effective Questionnaires. Thousand Oaks, CA: Sage Publications, 1999.
Strauss, J. y R. Frost. E-Marketing, 5ta. edición. Upper Saddle River, NJ: Pearson Prentice Hall, 2008.
Wansink, B., S. Sudman y N. M. Radburn. Asking Questions: The Definitive Guide to Questionnaire Design—For Market Re-
search, Political Polls, and Social and Health Questionnaires. Nueva York: Wiley, 2004.www.xlibros.com

128 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
E P I S O D I O 4
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Escucharé ahora, pregunto después
“He programado entrevistas preliminares con cinco personas clave. Como has estado muy ocupado con Visible Analyst, decidí
realizar la primera ronda de entrevistas por mi cuenta”, le dice Anna a Chip al iniciar su reunión matutina.
“Estoy de acuerdo”, dice Chip. “Sólo avísame cuando pueda participar. ¿Con quién vas a hablar primero? ¿Con Dot?”
“Creo que eso no es ningún secreto”, contesta Anna. “Ella es imprescindible para el éxito del sistema. Cuando se trata de
decidir si un proyecto continuará o no, su palabra es la definitiva”.
“¿Quién más?”, pregunta Chip.
“Voy a ver con quién me refiere Dot, pero también haré una cita con Mike Crowe, el experto de hardware y mantenimiento;
con Cher Ware, especialista de software; y con Paige Prynter, analista financiero de CPU”.
“No te olvides de Hy Perteks”, dice Chip.
“Cierto. El Centro de soporte de cómputo será importante para nuestro proyecto”, dice Anna. “Le llamaré para ver cuándo
está disponible”.
Después de una breve conversación telefónica con Hy, Anna vuelve con Chip.
“Se va a reunir conmigo más tarde el día de hoy”, confirma Anna.
Al terminar con sus entrevistas, Anna se sienta en su escritorio a repasar las síntesis de las entrevistas y los memos que se
recopilaron durante el verano. Hay varias pilas de papeles cuidadosamente archivados en carpetas expandibles.
“Tenemos tanta información”, le comenta a Chip, “pero incluso así siento que estamos trabajando sólo con la punta del
iceberg. No puedo comprender con claridad las dificultades de los miembros del cuerpo docente y el personal de investigación.
¿Habrá problemas adicionales de los que no hayamos escuchado?”
Chip mira hacia arriba al tiempo que deja el trabajo de intentar extraer puntos clave para definir los problemas. “Me pre-
gunto si deberíamos realizar más entrevistas, o tal vez recopilar más documentos”, dice.
“¿Pero cuántas entrevistas deberíamos realizar y a quién deberíamos entrevistar?”, le responde Anna. “Supón que entre-
vistamos a varios miembros del personal y basamos el nuevo sistema en los resultados. Podríamos entrevistar a las personas
equivocadas y diseñar un sistema para satisfacer sólo sus necesidades, omitiendo los problemas clave que la mayoría de los
miembros del cuerpo docente y del personal necesitan que se resuelvan”.
“Entiendo lo que quieres decir”, responde Chip. “Tal vez deberíamos diseñar un cuestionario y entrevistar al personal
docente y al de investigación”.
“¡Excelente idea!”, dice Anna. “¿Cómo deberíamos decidir qué preguntas incluir en la encuesta?”
“Hablemos con algunas personas clave y basemos la encuesta en los resultados. Un buen punto inicial sería Hy Perteks,
ya que siempre está hablando con el cuerpo docente y el personal. Le voy a llamar para programar una reunión”, dice Chip.
Chip programó la reunión para la mañana siguiente. Esta reunión se llevaría a cabo en una sala de conferencias adyacente
al Centro de soporte de cómputo.
“Gracias por aceptar esta cita con tan poca anticipación”, empieza Chip. “Estamos pensando en encuestar al cuerpo docente
y al personal de investigación para obtener información adicional que nos ayudará a definir las cuestiones relacionadas con el
sistema”.
“Creo que es una gran idea”, responde Hy. “También me gustaría averiguar qué tipo de software debería estar disponible
en el Centro de soporte de cómputo y el tipo de capacitación que deberíamos ofrecer. Deberíamos obtener información sobre
los principales paquetes de software utilizados”, continúa Hy. “El software de creación Web y videos es esencial. Deberíamos
averiguar qué paquetes prefiere cada usuario y la versión de éstos, que también es importante conocer. Sé que muchos utilizan
Dreamweaver y que otros utilizan Freeway Pro. El software de bases de datos también varía, aunque muchos utilizan Access.
Lo mismo ocurre con la creación de videos; Camtasia es el más popular”.
“Otra cosa que podríamos averiguar es qué tipo de software especializado utilizan los grupos de miembros del cuerpo
docente”, continúa Hy. “Muchas de las personas en el departamento de matemáticas utilizan Mathcad. Otros utilizan diversos
paquetes de software para una variedad de cursos. Por ejemplo, los de ciencias de la información utilizan Visio, pero unos
cuantos utilizan Visible Analyst. También he escuchado que vamos a recibir software de biología y astronomía. Y el departa-
mento de arte utiliza equipos Mac casi en forma exclusiva. Muchos de los miembros del cuerpo docente se están involucrando
mucho con software para construir imágenes, como Photoshop y Flash”.
“Además de los paquetes de software y las versiones, ¿qué tipos de información deberíamos capturar?”, pregunta Chip.
“Me gustaría saber el nivel de experiencia de cada persona”, responde Hy. “Sin duda algunos son principiantes, mientras
que otros tienen un buen conocimiento pero no han dominado todas las herramientas de un paquete específico. Algunos son
expertos. Conocen el software por dentro y por fuera. Estoy interesado en los principiantes y usuarios intermedios, ya que de-
beríamos ofrecer distintos niveles de capacitación para ellos. Saber quién es un experto ayuda también”.
“¿Hay algo más que crea usted que debamos averiguar en la encuesta?”, pregunta Chip.www.xlibros.com

CAPÍTULO 4 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 129
“La única otra cosa que me preocupa son los problemas que se producen cuando un miembro del cuerpo docente o del
personal no utiliza el software”, responde Hy.
“¿Qué quiere decir?”, pregunta Chip.
“Bueno, supongan que una persona tiene el software pero lo instaló en forma incorrecta o aparece algún tipo de mensaje
de seguridad o relacionado con los derechos de acceso”, responde Hy. “He recibido algunas consultas sobre esta cuestión re-
cientemente. Una persona dijo que estaban trabajando con Windows Vista y tenían su información en una unidad USB, y no les
concedía derechos de acceso. Rhoda Booke es miembro del cuerpo docente en matemáticas y ha demostrado de manera con-
sistente un interés en las cuestiones de hardware y software. Le he ayudado varias veces; siempre es amigable y agradecida.
Creo que deberían entrevistarla”.
“Gracias una vez más por toda su ayuda”, dice Chip. “Más adelante nos contactaremos con usted sobre los resultados de
la encuesta”.
Anna programa una reunión con Rhoda para explicarle la naturaleza del proyecto y por qué fue seleccionada como
representante del cuerpo docente. La reunión se sostuvo en una pequeña sala de conferencias en el departamento de ma-
temáticas.
“Nos gustaría conocer la perspectiva del cuerpo docente sobre los problemas relacionados con las computadoras y el soft-
ware asociado”, dice Anna. “Nuestro objetivo es ofrecer al cuerpo docente los mejores recursos posibles con el menor número
de problemas”.
“Estoy realmente encantada de formar parte del proyecto”, exclama Rhoda. “He utilizado software en el salón de clases
durante 10 años aproximadamente, ¡y ha sido toda una experiencia de aprendizaje! Gracias a Dios que Hy está disponible como
recurso. Le he robado horas de su tiempo, pero ha valido bien la pena. Me siento mucho más productiva y los estudiantes utili-
zan software que les ayuda a comprender el material con más detalle”.
“Eso es bueno. Ahora, ¿ha estado experimentando algunas dificultades?”, pregunta Chip.
“Bueno, es todo un reto familiarizarse con el software. Invertí una buena parte del verano pasado, cuando no estaba traba-
jando en mi libro, en aprender cómo usar parte del software del salón de clases para álgebra y cálculo. Es grandioso pero quedé
atrapada varias veces y tuve que pedir ayuda. Es necesario entender el software para preparar los planes de las lecciones y ex-
plicar a los estudiantes cómo usarlo”.
“¿Qué hay sobre problemas al instalar el software o hardware?”, pregunta Anna.
“¡Oh si!”, exclama Rhoda. “Traté de instalar el software y todo salió bien hasta llegar a la parte en donde tenía que recibir
actualizaciones de su sitio Web y hubo algunos problemas con el registro”, se ríe Rhoda.
“Después hubo problemas de instalación”, continúa Rhoda. “Necesitaba averiguar qué instalar en la red y qué incluir en
el disco duro local. En algunas laptops obtuvimos mensajes de error del tipo “Memoria insuficiente” y descubrimos que nunca
se habían actualizado. El cuerpo docente del departamento de física tuvo el mismo problema”.
“¿Hay alguna otra cuestión que usted considere importante para incluirla en nuestra encuesta para el personal docente y
de investigación?”, pregunta Chip.
“Sería conveniente saber quién utiliza el mismo software en distintos departamentos y qué software suministra cada dis-
tribuidor. Tal vez si compramos muchos paquetes de un distribuidor podríamos obtener un mayor descuento por el software. El
presupuesto de software del departamento ya está sobrecargado”, dice Rhoda.
“Gracias por toda su ayuda”, dice Anna. “Si llega a pensar en alguna pregunta adicional que debamos incluir en la encuesta,
no dude en llamarnos”.
De vuelta en su oficina, los analistas empiezan a compilar una lista de las cuestiones que debe contener la encuesta.
“En definitiva necesitamos preguntar sobre el software en uso y las necesidades de capacitación”, comenta Anna. “También
deberíamos tratar con los problemas que están ocurriendo”.
“De acuerdo”, responde Chip. “Creo que deberíamos incluir preguntas sobre los paquetes de software, distribuidores,
versiones, nivel de experiencia y cuestiones relacionadas con la capacitación. De lo que no estoy muy seguro es de cómo obte-
ner información sobre los problemas a los que se enfrenta el personal docente y de investigación. ¿Cómo deberíamos abordar
esas cuestiones?”
“Bueno”, responde Anna, “deberíamos enfocarnos en las cuestiones con las que estén familiarizados. Podríamos
hacer preguntas sobre el tipo de problemas que están ocurriendo, pero que en definitiva no sean técnicos. Y la encuesta
no debería hacer preguntas cuyas respuestas pudiéramos encontrar con facilidad, como “¿Quién es el distribuidor del
software?”
“Entiendo”, responde Chip. “Dividamos las preguntas en categorías. Algunas serán preguntas cerradas y otras abiertas.
Después hay que ver qué estructura debemos usar”.
“Usaremos Zoomerang para administrar la encuesta en Web”, continúa Anna. “También usaremos recordatorios vía correo
electrónico sobre la fecha de terminación de la encuesta”.www.xlibros.com

130 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EJERCICIOS
En los primeros tres ejercicios tendrá que visitar el sitio Web para obtener el texto de las entrevistas con los miembros del per-
sonal de la CPU. Visite el sitio Web en www.pearsonhighered.com/kendall y busque las entrevistas de la CPU (“CPU Inter-
views”).
E-1. Analice las cinco entrevistas. En un párrafo describa el tipo de estructura que tenía cada entrevista.
E-2. Elabore una lista de todas las entrevistas, de 1 a 5, y después escriba un párrafo para cada una de ellas en el que describa
las formas en que Anna podría mejorar sus entrevistas para la próxima vez.
E-3. Analice las preguntas utilizadas en las cinco entrevistas. Describa en un párrafo los tipos de preguntas utilizadas y si
fueron o no apropiadas para obtener la información necesaria.
E-4. De la lista de asuntos presentada anteriormente en el capítulo, seleccione las cuestiones que quedarían mejor como pre-
guntas cerradas.
E-5. De la lista de asuntos, seleccione las cuestiones que quedarían mejor como preguntas abiertas.
E-6. En base a los ejercicios E-4 y E-5, diseñe un cuestionario que se envíe al cuerpo docente y al personal de investigación.
E-7. Haga una prueba piloto de su cuestionario; deje que otros estudiantes de la clase lo llenen. En base a la retroalimentación
de los estudiantes y a la capacidad que usted tenga de analizar los datos que reciba, revise su cuestionario.www.xlibros.com

131
C A P Í T U L O 5
Recopilación de información:
métodos discretos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Reconocer el valor de los métodos discretos para recopilar información.
2. Comprender el concepto del muestreo para el análisis de los requerimientos humanos
de información.
3. Construir muestreos útiles de personas, documentos y eventos para determinar los
requerimientos humanos de información.
4. Crear un guión (playscript) para que el analista pueda observar las actividades de toma
de decisiones.
5. Aplicar la técnica STROBE para observar e interpretar el entorno del encargado de las
decisiones y su interacción con las tecnologías.
Aunque con sólo estar presente en una organización el analista de siste-
mas genera un cambio en la misma, hay métodos discretos “como el
muestreo, la investigación y la observación del comportamiento del encar-
gado de las decisiones y su interacción con su entorno físico” menos per-
turbadores que otras formas de averiguar los requerimientos humanos de
información. Los métodos discretos se consideran insuficientes para recopilar información
cuando se utilizan por sí solos, por lo que deben utilizarse junto con uno o varios de los méto-
dos interactivos descritos en el capítulo anterior. A esto se le conoce como metodología mixta.
Utilizar métodos interactivos y discretos para acercarse a la organización es una práctica inte-
ligente mediante la cual podrá formarse un panorama más completo de los requerimientos
humanos de información.
MUESTREO
El muestreo es el proceso de seleccionar sistemáticamente elementos representativos de una
población. Cuando se examinan con detalle estos elementos seleccionados, se asume que el
análisis revela información útil sobre la población en general.
El analista de sistemas debe decidir con respecto a dos cuestiones clave. En primer lugar
hay muchos informes, formularios, documentos de resultados, memos y sitios Web que las
personas en la organización han generado. ¿A cuáles de ellos debe el analista poner atención y
cuáles debe ignorar?
En segundo lugar, muchos empleados se pueden ver afectados por el sistema de informa-
ción propuesto. ¿A quiénes debería entrevistar el analista de sistemas?, ¿de quienes debería
buscar información por medio de cuestionarios?, ¿a quienes debería observar en el proceso de
llevar a cabo sus roles de toma de decisiones?www.xlibros.com

132 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
La necesidad del muestreo
Un analista de sistemas debe seleccionar una muestra representativa de datos para examinarlos o de personas
representativas para entrevistarlas, interrogarlas u observarlas por varias razones:
1. Contener los costos.
2. Agilizar el proceso de recopilación de datos.
3. Mejorar la efectividad.
4. Reducir la predisposición.
Examinar cada hoja de papel, hablar con todos y leer todas las páginas Web de la organización sería un pro-
ceso demasiado costoso para el analista de sistemas. Copiar informes, acaparar el valioso tiempo de los emplea-
dos y duplicar encuestas inútiles representaría un gran gasto innecesario.
El muestreo ayuda a acelerar el proceso mediante la recopilación de datos seleccionados, en vez de recopilar
todos los datos de toda la población. Además, el analista de sistemas se evita la molestia de tener que analizar los
datos de toda la población.
La efectividad en la recopilación de los datos también es un factor importante. El muestreo ayuda a mejo-
rar la efectividad si se permite obtener información más precisa. Por ejemplo, puede hablar con menos emplea-
dos, pero debe hacerles preguntas más detalladas. Además, si se entrevista a menos personas, el analista tendrá
tiempo para dar seguimiento a la información incompleta o faltante, con lo cual se mejorará la efectividad de la
recopilación de datos.
Por último, el muestreo permite reducir la predisposición durante el proceso de recopilación de datos. Por
ejemplo, cuando el analista de sistemas entrevista a un ejecutivo, éste se involucra con el proyecto, dado que cedió
una parte de su tiempo, y le gustaría que el proyecto triunfara. Cuando el analista de sistemas pide una opinión
sobre una característica permanente del sistema de información instalado, el ejecutivo tal vez provea una eva-
luación predispuesta, ya que hay poca probabilidad de cambiar esa característica.
Diseño del muestreo
Un analista de sistemas debe seguir cuatro pasos para diseñar una buena muestra:
1. Determinar los datos a recolectar o describir.
2. Determinar la población a muestrear.
3. Elegir el tipo de muestra.
4. Decidir sobre el tamaño de la muestra.
En las siguientes subsecciones describiremos estos pasos con detalle.
DETERMINAR LOS DATOS A RECOLECTAR O DESCRIBIR El analista de sistemas necesita elaborar un plan realista
en cuanto a lo que debe hacer con los datos después de recolectarlos. Si se recopilan datos irrelevantes se
desperdicia tiempo y dinero en la recolección, el almacenamiento y el análisis de datos inútiles.
Los deberes y responsabilidades del analista de sistemas en esta etapa consisten en identificar las variables,
atributos y elementos de datos asociados a recopilar en la muestra. Hay que considerar los objetivos del estudio,
así como el tipo de método de recopilación de datos (investigación, entrevistas, cuestionarios, observación) a uti-
lizar. Éste y los siguientes capítulos describen con más detalle los tipos de información que debe buscar al usar
cada uno de estos métodos.
DETERMINAR LA POBLACIÓN A MUESTREAR A continuación, el analista de sistemas debe determinar cuál es la
población; en caso de muestrear datos rigurosos, necesita decidir, por ejemplo, si basta con los últimos dos meses
o si se requiere todo un año de informes para el análisis.
De manera similar, al decidir a quién va a entrevistar, el analista de sistemas tiene que determinar si la po-
blación incluirá uno o todos los niveles de la organización, o incluso si debe considerar a clientes, distribuidores,
proveedores o competidores. En los capítulos sobre entrevistas, cuestionarios y observación exploraremos con
más detalle estas decisiones.
ELEGIR EL TIPO DE MUESTRA. Como se indica en la figura 5.1, el analista de sistemas puede usar uno de cuatro
tipos principales de muestras: de conveniencia, intencionada, simple y compleja. Las de conveniencia son
muestras sin restricciones ni probabilidades. Una muestra de este tipo resultaría de que el analista de sistemas
publicara un aviso en la intranet de la empresa para pedir que los interesados en trabajar con los nuevos informeswww.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 133
Los elementos de la
muestra se seleccionan
directamente sin
restricciones
De conveniencia Simple aleatoria
Los elementos de la
muestra se seleccionan
de acuerdo a ciertos
criterios
Compleja aleatoria
(sistemática, estratificada
y de conglomerados)
Intencionada
No se basa en la probabilidad Se basa en la probabilidad
El analista de
sistemas debe usar
una muestra compleja
aleatoria si fuera
posible.
FIGURA 5.1
Cuatro tipos principales de
muestras disponibles para el
analista.
de rendimiento de ventas fueran a una reunión a la 1 P.M. el martes 12. Sin duda es la más fácil de preparar, pero
es también la menos confiable. Una muestra intencionada se basa en el juicio.
El analista de sistemas puede elegir un grupo de individuos que parezcan expertos y estén interesados
en el nuevo sistema de información. Aquí, el muestreo se basa en los criterios de conocimiento e interés
sobre el nuevo sistema, pero de todas formas es un muestreo sin probabilidad. Por ende, el muestreo in-
tencionado es confiable sólo en un nivel moderado. Si elige realizar un muestreo aleatorio simple, necesita
obtener una lista numerada de la población para asegurar que cada documento o persona en la población
tenga la misma probabilidad de ser seleccionada. A menudo este paso no es práctico, en especial cuando el
muestreo involucra documentos e informes. Las muestras aleatorias complejas más apropiadas para el ana-
lista de sistemas se obtienen mediante 1) muestreo sistemático, 2) muestreo estratificado y 3) muestreo de
conglomerados.
Por ejemplo, en el método más simple de muestreo de probabilidad –el sistemático–, el analista de sistemas
debe elegir entrevistar a cada k-ésima persona en una lista de empleados de la empresa. Este método tiene
ciertas desventajas: no es conveniente utilizarlo para seleccionar cada k-ésimo día para una muestra, debido al
potencial problema de periodicidad; tampoco sería apropiado aplicarlo a una lista ordenada (por ejemplo, una
lista de bancos, desde el más pequeño hasta el más grande), ya que habría una predisposición.
El muestreo estratificado tal vez sea el más importante para el analista de sistemas. La estratificación
es el proceso de identificar subpoblaciones o estratos, para después seleccionar objetos o personas con los
que se realicen muestras de estas subpoblaciones. A menudo, la estratificación es esencial si el analista de
sistemas desea recopilar datos con eficiencia. Por ejemplo, si desea buscar opiniones de un amplio rango
de empleados en distintos niveles de la organización, el muestreo sistemático seleccionaría un número despro-
porcionado de empleados del nivel de control operacional. Una muestra estratificada compensaría esta situa-
ción. También se utiliza la estratificación cuando el analista de sistemas desea usar distintos métodos para
recolectar datos de distintos subgrupos. Por ejemplo, tal vez quiera utilizar una encuesta para recopilar datos
de los gerentes de nivel medio, pero podría preferir usar entrevistas personales para recopilar datos similares de
los ejecutivos.
Algunas veces el analista de sistemas debe seleccionar un grupo de personas o documentos para estudiarlos.
A este proceso se le conoce como muestreo de conglomerados. Suponga que una organización tiene 20 centros
de soporte esparcidos en todo el país. Tal vez usted quiera seleccionar uno o dos de estos centros de soporte bajo
la suposición de que son comunes con el resto.
DECIDIR SOBRE EL TAMAÑO DE LA MUESTRA En definitiva, si todos en la población vieran el mundo de la
misma forma, o si cada uno de los documentos de una población tuviera exactamente la misma información
que cualquier otro, sería suficiente una muestra con tamaño de uno. Como no es así, es necesario establecer un
tamaño de muestra mayor, pero menor que el de la población.
Es importante recordar que, en el muestreo, el número absoluto es más importante que el porcentaje
de la población: es posible obtener resultados satisfactorios muestreando 20 personas tanto de 200 como de
2,000,000.www.xlibros.com

134 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
La decisión sobre el tamaño de las muestras
A menudo, el tamaño de las muestras depende del costo o el tiempo requerido por el analista de sistemas, o in-
cluso del tiempo disponible de las personas en la organización. Esta subsección ofrece varios lineamientos para
determinar el tamaño de muestra requerido en condiciones ideales; por ejemplo, para determinar el porcentaje de
formas de entrada que contienen errores, o qué proporción de personas hay que entrevistar.
Para definir el tamaño de muestra requerido, el analista de sistemas debe seguir siete pasos, algunos de los
cuales implican juicios subjetivos:
1. Determinar el atributo (en este caso, el tipo de errores a buscar).
2. Localizar la base de datos o los informes en los que se pueda encontrar el atributo.
3. Examinar el atributo. Estimar p, la proporción de la población que cuenta con el atributo.
4. Tomar la decisión subjetiva en relación con la estimación del intervalo aceptable, i.
5. Elegir el nivel de confianza y buscar el coeficiente de confianza (valor z) en una tabla.
6. Calcular p, el error estándar de la proporción, de la siguiente manera:
p = i
z
7. Determinar el tamaño de muestra necesario, n, mediante la siguiente fórmula:
n = p11 - p 2
2
p
+ 1
Desde luego, el primer paso es determinar el atributo a muestrear; después puede averiguar dónde se almacenan
estos datos: una base de datos, un formulario, un informe, etcétera.
Es importante estimar p, la proporción de la población que tiene el atributo, para establecer el tamaño de
muestra apropiado. Muchos libros de texto sobre análisis de sistemas sugieren utilizar un heurístico de 0.25 para
p(1 - p). Este valor casi siempre produce muestra de tamaño mayor que el necesario, ya que 0.25 es el valor
máximo de p(1 - p), que ocurre sólo cuando p = 0.50. Cuando p = 0.10, como es más comúnmente el caso,
p(1 - p) se convierte en 0.09, con lo cual se obtiene un tamaño de muestra mucho menor.
Los pasos 4 y 5 implican decisiones subjetivas. La estimación de intervalo aceptable de ±10 significa que
está dispuesto a aceptar un error de no más de 0.10 en cualquier dirección de la proporción actual, p. El nivel de
confianza es el grado deseado de certidumbre; por ejemplo, del 95 por ciento. Una vez elegido el nivel de con-
fianza, puede buscar el coeficiente de confianza (también conocido como valor z) en una tabla como la que se
encuentra en este capítulo.
Los pasos 6 y 7 completan el proceso al recibir los parámetros de los pasos 3 al 5 e introducirlos en dos
ecuaciones para resolver el tamaño de muestra requerido.
Ejemplo
Vamos a ilustrar con un ejemplo los pasos mencionados. Suponga que la empresa A. Sembly, que se
dedica a la fabricación de productos de estantería, le pide determinar el porcentaje de pedidos que
contienen errores. Usted acepta hacer este trabajo y lleva a cabo los siguientes pasos:
1. Determina que va a buscar pedidos con errores en nombres, direcciones, cantidades o números de
modelos.
2. Localiza las copias de los formularios de pedido de los últimos seis meses.
3. Examina algunos de los formularios de pedido y concluye que sólo cerca del 5 por ciento (0.05)
contiene errores.
4. Juzga que la estimación de intervalo aceptable será de ±0.02.
5. Selecciona un nivel de confianza de 95 por ciento. Busque el coeficiente de confianza (valor z) en la
figura 5.2. El valor z es igual a 1.96.
6. Calcula p de la siguiente manera:
p = i
z = 0.02
1.96 = 0.0102
7. Determina el tamaño de muestra necesario n de la siguiente manera:
n = p11 - p 2
2
p
+ 1 = 0.0510.95 2
10.0102 2 10.0102 2 + 1 = 458www.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 135
99% 2.58
98 2.33
97 2.17
96 2.05
95 1.96
90 1.65
80 1.28
50 0.67
Nivel de
confianza
Coeficiente
de confianza
(valor z)
Primero hay que
decidir sobre el
nivel de confianza...
... después hay
que buscar el
valor z.
FIGURA 5.2
Podemos utilizar una tabla del
área bajo una curva normal para
buscar un valor, una vez que el
analista de sistemas decida sobre
el nivel de confianza.
Entonces, la conclusión es establecer el tamaño de la muestra en 458. En definitiva, un nivel mayor de confianza o
una estimación de intervalo aceptable menor requerirían una muestra mayor. Si mantenemos igual la estimación
del intervalo aceptable pero aumentamos el nivel de confianza al 99 por ciento (con un valor z de 2.58), el
tamaño de muestra necesario se convierte en 1.827, una cifra mucho mayor que los 458 pedidos que habíamos
decidido muestrear en un principio.
O P O R T U N I D A D D E C O N S U L T O R Í A 5 . 1
A la caza de una muestra
“¿Es genuina o artificial? ¿Quién lo hubiera pensado, incluso
hace cinco años!”, exclama Sam Pelt, un peletero propietario de
tiendas en Nueva York, Washington, D.C., Beverly Hills y Copen-
hague. Sylva Foxx, analista de sistemas y propietaria de una em-
presa de consultoría, está hablando con Sam por primera vez.
Actualmente, P & P, Ltd. (Pelt y Pelt hijo) utiliza una PC para llevar
la lista de correo de clientes selectos, las cuentas por pagar, las
cuentas por cobrar y la nómina.
Sam está interesado en tomar ciertas decisiones estratégicas
que afectarán la compra de productos para sus cuatro tiendas de
pieles. Cree que, aunque la computadora podría ayudar, también
hay que considerar otras metodologías.
Sam continúa: “Creo que deberíamos hablar con todos los
clientes cuando entren a la tienda, conocer sus opiniones. A algunos
les indigna el uso de pieles de animales en peligro de extinción;
tienen una orientación ambientalista. Si de esa manera pueden sal-
var a un cachorro, eligen las imitaciones. Algunos incluso prefieren
las imitaciones y les llaman ‘pieles divertidas’. Y yo puedo cobrar
casi lo mismo por una buena imitación.
“Pero hay un riesgo: si me alejo demasiado de mis proveedores
de pieles, tal vez no obtenga lo que quiera cuando lo necesite. Ellos
ven a los distribuidores de pieles de imitación como si fueran gusa-
nos, ¡peores que polillas! Si hago negocios con ellos, tal vez los
distribuidores de pieles auténticas ya no quieran hablarme. Pueden
ser animales. Por otro lado, me siento raro en cuanto a exhibir imi-
taciones en mis tiendas. Durante años nos hemos enorgullecido de
tener sólo artículos genuinos”.
Sam continúa, en un monólogo casi continuo: “Quiero hablar
con todos y cada uno de los empleados, también”.
Sylva lo mira con disimulo y empieza a interrumpir: “Pero eso
llevará meses y las compras se derrumbarán por completo a menos
que sepan con prontitud qué...”.
Pelt la interrumpe: “No me importa cuánto tarde, mientras
obtengamos respuestas correctas. Pero tienen que ser las correctas.
Me siento como un leopardo sin sus manchas por no saber cómo
resolver este dilema de las pieles de imitación”.
Sylva habla con Sam Pelt un poco más y después termina la
entrevista diciendo: “Voy a comentarlo con los otros analistas en
la oficina y le haré saber nuestra resolución. Creo que podemos
aventajar a los otros peleteros si utilizamos software que nos ayude a
obtener muestras de las opiniones, en lugar de cazar a los clientes
para que nos digan lo que piensan, pero le haré saber lo que digan
los demás. Lo que puedo asegurarle es que si podemos obtener
muestras sin tener que hablar con todos antes de tomar una deci-
sión, usted saldrá ganando”.
Como uno de los analistas de sistemas que forma parte de la
empresa de Sylva Foxx, sugiera algunas formas en las que Sam Pelt
pueda usar software en su PC para obtener muestras adecuadas de
las opiniones de sus clientes, gerentes de las tiendas, compradores
y cualquier otra persona que usted considere imprescindible para
tomar la decisión estratégica en relación con el abastecimiento de
pieles de imitación en lo que siempre ha sido una tienda de pieles
genuinas. Sugiera un tipo de muestra para cada grupo y justifíquelo.
Usted estará restringido por la necesidad de actuar con rapidez para
seguir siendo competitivo, la necesidad de actuar sigilosamente
para que los peleteros de la competencia no se enteren de que usted
está recopilando datos, y la necesidad de mantener los costos de la
recopilación de datos en un nivel razonable.www.xlibros.com

136 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
DETERMINACIÓN DEL TAMAÑO DE LAS MUESTRAS PARA ENTREVISTAS No hay fórmulas mágicas para ayudar al
analista de sistemas a establecer el tamaño de la muestra para entrevistas; la variable primordial en este caso es
el tiempo que tarda una entrevista. Una entrevista profunda y una de seguimiento consumen mucho tiempo, tanto
del entrevistador como del participante.
Una buena regla general es entrevistar a por lo menos tres personas en todos los niveles de la organización, y
a por lo menos una de cada una de las áreas funcionales (como vimos en el capítulo 2) que trabajen directamente
con un sistema nuevo o actualizado. Recuerde también que no es necesario entrevistar a más personas sólo por-
que se trate de una empresa más grande. Si el muestreo estratificado se lleva a cabo en forma apropiada, pocos
individuos representarán de manera adecuada a toda la organización.
INVESTIGACIÓN
Investigar es descubrir y analizar información. Al investigar la evidencia en una organización, el analista actúa
como Sherlock Holmes, el famoso detective.
A medida que el analista de sistemas trabaja para entender a los usuarios, su organización y sus requerimien-
tos de información, debe examinar los distintos tipos de datos “duros” que ofrecen información no disponible por
cualquier otro medio de recopilación. Estos datos revelan dónde ha estado la organización y hacia dónde creen
sus miembros que se dirige. Para formarse una imagen precisa, el analista necesita examinar datos tanto cuanti-
tativos como cualitativos.
Análisis de documentos cuantitativos
Hay muchos documentos cuantitativos disponibles para su interpretación en cualquier empresa: informes em-
pleados para la toma de decisiones, informes de rendimiento, registros y variados tipos de formularios. Todos
estos documentos tienen un propósito y una audiencia específicos.
INFORMES PARA LA TOMA DE DECISIONES El analista de sistemas requiere acceso a algunos de los documentos
utilizados para dirigir la empresa. A menudo consisten en informes sobre el estado del inventario, las ventas o la
producción. Muchos de ellos son simples y su función es dar apoyo a una acción rápida. Por ejemplo, un informe
de ventas puede sintetizar la cantidad que se vendió y el tipo de ventas. Además, los informes de ventas podrían
incluir resultados gráficos para comparar los ingresos y las entradas durante ciertos periodos. Dichos informes
permiten que el encargado de tomar las decisiones reconozca fácilmente las tendencias.
Los informes de producción incluyen los costos recientes, el inventario actual, la mano de obra reciente y la
información de la planta. Además de estos informes clave, los encargados de tomar las decisiones utilizan mu-
chos informes sintetizados para proveer información de apoyo, detectar las excepciones a las ocurrencias norma-
les y obtener vistas generales estratégicas de los planes de la organización.
INFORMES DE RENDIMIENTO La mayoría de los informes de rendimiento consisten en una comparación entre el
rendimiento actual y el esperado. Una función importante de ellos es medir la brecha entre el rendimiento actual
y el esperado. También es importante poder determinar si ese hueco se está ensanchando o estrechando como
una tendencia general en cualquier rendimiento en evaluación. En la figura 5.3 se muestra una clara mejoría en el
rendimiento de las ventas durante un periodo de dos a tres meses. Es probable que el analista quiera observar si
hay una medición del rendimiento disponible y adecuada para las áreas clave de la organización.
REGISTROS Los registros proveen actualizaciones periódicas de lo que ocurre en la empresa. Si el encargado del
registro es cuidadoso y lo actualiza en forma oportuna, puede proveer mucha información útil para el analista.
En la figura 5.4 se muestra un registro de pagos que se llenó a mano para la renta de un apartamento. Hay varias
formas en que el analista puede inspeccionar un registro, muchas de las cuales son indicativas de su capacidad
de uso:
1. Revisar errores en montos y totales.
2. Buscar oportunidades para mejorar el diseño de los formularios de registro.
3. Observar el número y tipo de transacciones.
4. Estar al tanto de los casos en los que la computadora pueda simplificar el trabajo (por ejemplo, los cálculos
y otras formas de manipular los datos).
FORMULARIOS DE CAPTURA DE DATOS Antes de disponerse a cambiar los flujos de información de la
organización, hay que entender el sistema que está en uso en ese momento. Tal vez sea conveniente que usted owww.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 137
Número de
lotes
producidos
Número de
lotes
rechazados
Porcentaje
rechazado
Monto que se
aleja del
objetivo del 5%
Semana
2/2 245 19 7.8 2.8
2/9 229 19 8.3 3.3
2/16 219 14 6.3 1.3
2/23 252 13 5.2 0.2
3/2 245 13 5.3 0.3
3/9 260 13 5.0 * * *
3/16 275 14 5.1 0.1
3/23 260 13 5.0 * * *
3/30 260 13 5.0 * * *
4/6 244 12 4.9 * * *
4/13 242 11 4.5 * * *
4/20 249 11 4.4 * * *
4/27 249 11 4.4 * * *
* * * indica que se cumplió o excedió el objetivo de < 5%
... y las tendencias
Los informes de
rendimiento
muestran los
objetivos ...
FIGURA 5.3
Un informe de rendimiento que
muestra mejorías.
O P O R T U N I D A D D E C O N S U L T O R Í A 5 . 2
Una rosa con otro nombre... o Calidad mejor que cantidad
“Creo que tenemos lo necesario. Llevé a cabo el muestreo de
estados financieros, cifras de ventas de todas las sucursales, mermas
de todas las tiendas, todo. Con esos números tenemos que ser capa-
ces de mantener a Fields en el campo... o por lo menos a la cabeza
del negocio de las florerías. Incluso podremos enseñarle al mismo
Seymour Fields cómo su nuevo sistema de computación puede ge-
nerar todo esto”, expresa Rod Golden, un analista de sistemas junior
que trabaja para un despacho de consultoría mediano.
La empresa, bajo la supervisión del analista líder Clay Potts,
ha estado trabajando en un proyecto de sistemas para Fields, una
cadena de 15 exitosas florerías y establecimientos de flores para
interiores. En cada una de tres ciudades del Medio Oeste de Estados
Unidos hay cinco tiendas de Fields.
“Aunque por el momento es una empresa floreciente, que-
remos ramificarnos a por lo menos seis estados”, indica Seymour
Fields, el propietario. “Quiero cosechar los beneficios de toda la
felicidad que hemos estado sembrando. Y creo que podemos
lograrlo basándonos en mis corazonadas con respecto a cuál es
la mejor temporada para adquirir flores en los mercados euro-
peos de los que ya compramos, y luego podar nuestras adquisi-
ciones”.
“Durante los últimos tres años, he escrito montones de memos
a nuestros gerentes acerca de este plan; ellos también han escrito
una buena cantidad de ellos. Creo que pronto estaremos listos para
plantar este proyecto”, continua Seymour, describiendo un futuro
color de rosa para Fields.
“Estoy de acuerdo”, dice Rod. “Cuando regrese de analizar
estas cifras”, agrega, señalando el altero de material que ha desen-
terrado de las oficinas de Fields, “le entregaré resultados”.
Tres semanas después, Rod regresa a hablar con Clay sin mu-
cha determinación. “No sé qué concluir de todo esto. No doy con lo
que está produciendo el crecimiento de la compañía, ni con la forma
en que están administrándolo. Han estado creciendo, pero aunque
he analizado todas las cifras, no encuentro un patrón todavía.”
Clays lo escucha con paciencia y dice: “Sin embargo, has he-
cho que me brote una idea. Lo que se requiere es polinización cru-
zada y mucho oxígeno. Tenemos que escarbar más. ¿Examinaste
todo, menos el fondo?”
Rod responde, desconcertado: “No... eh... ¿a qué te refieres?”
¿Cómo puede Clay Potts explicarle de manera sutil a Rod
Golden que es importante analizar tanto los datos cuantitativos
como la información cualitativa para elaborar una evaluación apro-
piada del potencial de Fields para convertirse en una empresa más
fructífera? En un párrafo, recomiende documentos específicos a
leer. Enumere los pasos específicos que Rod debe seguir para eva-
luar los documentos de información cualitativa obtenidos de Fields.
Escriba un párrafo que explique cómo los documentos cualitativos
ayudan a presentar un panorama exhaustivo del éxito de Fields.www.xlibros.com

138 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
REGISTRO DE PAGO: Tot. 31175/0 + 81299 + Renta = 910
TOTAL DE PAGO INICIAL REQUERIDO:
855 55 910 H/S dep. 4Fecha
venc.
Fecha
pago
Recibo
Núm.
Pago al
mediodía Total
renta Segu-
ridad Lim-
pieza 31700
81299
Otros Monto
pagado Saldo
restanteImp.
Fechas
Monto
Descr.
Mont.
TV 10 /3 MO ! 8/28 8/28 106642 9/30 1031.32 202 115 44.20 25
414.82
15 1430.52 0
10/1 10/ 3 107503 10/31 910 910 0
11 / 1 11/ 1 10935 11/ 16 485.28 485.28 0
C1H/S9-16 11/17 11/8 11200 11/ 23 212.31 212.31 0
Cobrar 1 MES 11/24
Prorrateado
Hay que crear H/S
para reembolsar
depósito.
EDIFICIO # NOMBRE
Fecha original en que se mudó d Exp. x #
Renta
base Refri-
gerador Mue-
bles
Total
renta Segu-
ridad Lim-
pieza
31700
Imp.
Tarifa
diaria
8-28 igual 1
Kendall 1 ero
NOMBRE PROY. # FIRMA CLAVE
POTENCIAL RENTA 1175/0 81299
PRORRATEO
A/C Ser-
vicios HMSR T.V. Muca-
ma 31175/0 81299 Días Totales
POTENCIAL
DEPÓSITO
Depósitos
Sólo memo 31175/0
OAK. FC 562
H/S
rent 30. 33 1.30 910
39
200 115 31.63 340
1430.52
15 .00
121 . 32
5 . 20
Trate de detectar
los lugares donde la
computadora pueda
simplificar el trabajo.
Observe el número y
tipo de transacciones
Verifique los errores.
Busque
oportunidades de
mejorar el diseño.
FIGURA 5.4
Un registro de pago que se llenó a
mano.
uno de los miembros de su equipo recopilen y clasifiquen una copia en blanco de cada formulario (oficial y no
oficial) en uso (algunas veces las empresas ya cuentan con alguien encargado de administrar los formularios; esta
persona será su primera fuente para saber qué formularios se utilizan).
Podemos comparar los formularios en blanco, junto con sus instrucciones de llenado y distribución, con los
formularios llenos, para detectar alguna consistencia en cuanto a los elementos de datos que se hayan dejado en
blanco, verificar si las personas que se supone deben recibir los formularios en realidad los están recibiendo y
determinar si siguen los procedimientos estándar para usar, almacenar y desechar los formularios. Recuerde im-
primir cualquier formulario basado en Web que los usuarios tengan que imprimir. Como alternativa puede iden-
tificar y almacenar las versiones electrónicas de los formularios que se puedan enviar a través de Web o correo
electrónico, para almacenarlas en una base de datos e inspeccionarlas después.
Una vez que haya creado un catálogo de formularios que lo ayuden a entender el flujo de información que se
utiliza en la empresa en ese momento, lo que debe hacer a continuación es:
1. Recolectar ejemplos de todos los formularios en uso, sin importar que estén aprobados o no por la empresa
(formularios oficiales vs. formularios clandestinos).
2. Observar el tipo de formulario (impreso dentro de la empresa, escrito a mano, generado por computadora
dentro de la empresa, formularios en línea, formularios para llenar en Web, formularios que se imprimen y
compran de manera externa, etcétera).
3. Documentar el patrón de distribución deseado.
4. Comparar el patrón de distribución deseado con quienes realmente recibieron el formulario.
Aunque este procedimiento lleva tiempo, es útil. Otra metodología es muestrear los formularios de captura
de datos que ya estén llenos. Recuerde verificar las bases de datos que almacenan los datos de los consumidores
al muestrear la entrada de las transacciones de comercio electrónico. El analista debe tener en cuenta muchaswww.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 139
preguntas específicas, como se muestra en la figura 5.5. Éstas incluyen los siguientes aspectos de HCI en rela-
ción con la capacidad de uso, la estética y la utilidad:
1. ¿Se llenó el formulario en su totalidad? Si no fue así, ¿qué elementos se omitieron?, ¿hubo consistencia en
los elementos omitidos? ¿Por qué?
2. ¿Hay formularios que nunca se usaron? ¿Por qué? (Revise el diseño y la precisión de cada formulario en
cuanto a su supuesta función).
3. ¿Se enviaron todas las copias de los formularios a las personas apropiadas o se archivaron en forma
apropiada? De no ser así, ¿por qué no? Las personas que deben acceder a los formularios en línea, ¿pueden
hacerlo?
4. Si hay un formulario en papel que se ofrece como alternativa a un formulario basado en Web, compare las
tasas de compleción de ambos.
5. ¿Se utilizan formularios “no oficiales” con regularidad? (Su uso podría indicar un problema en los
procedimientos estándar o batallas políticas en la organización).
Fecha Nombre de la tienda Nombre de la tienda
Producto Unidades Producto Unidades
Leche (1/2 galones) Leche (litros)
Entera Entera
2% 2%
1% 1%
Descremada Descremada
Suero de leche Suero de leche
Chocolate Chocolate
Yogurt
Natural Piña
Vainilla Manzana holandesa
Durazno Plátano
Arándano Fruta mixta
Mora Frambuesa
Fresa Limón
Helado
Cuartos de litro de lujo Litros de lujo
1/2 galones de lujo Cuartos Premium
Miniaturas descremadas
Litros Premium
Solicitado por (número de empleado) Total de cajas ordenadas
Razón de la baja existenciaNúmero de conductor
Número de ruta
Reabastecimiento de productos
lácteos con poca existencia
Un formulario oficial
puede abrumar a las
personas al pedir
demasiada
información.
Tal vez el formulario
no tenga un orden
lógico.
¿Se requiere
realmente el
total?
Surgen formularios
“clandestinos” para
simplificar el
problema.
Tienda Fecha Conductor
Producto agotado Cajas necesarias
Iniciales del gerente de lácteos
FIGURA 5.5
Preguntas por hacer sobre los
formularios oficiales y
clandestinos que ya estén llenos.www.xlibros.com

140 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Análisis de los documentos cualitativos
Los documentos cualitativos incluyen mensajes de correo electrónico, memorandos, anuncios en tableros y áreas
de trabajo, páginas Web, manuales de procedimientos y de políticas. Muchos de estos documentos contienen
gran cantidad de detalles que revelan las expectativas de los autores con respecto al comportamiento de los de-
más, junto con las formas en que los usuarios esperan interactuar con las tecnologías de información.
Aunque muchos analistas de sistemas son aprensivos en cuanto al análisis de documentos cualitativos, no
tienen razón para serlo. Varios lineamientos pueden ayudar a los analistas a adoptar un enfoque sistemático para
este tipo de análisis; muchos se relacionan con los aspectos afectivos, emotivos y motivacionales de HCI, así
como las relaciones interpersonales en la organización.
1. Examine los documentos en busca de metáforas clave o que sirvan como guía.
2. Busque discrepancias entre internos contra externos o una mentalidad del tipo “nosotros contra ellos”.
3. Haga una lista de los términos que caractericen el bien o el mal y que aparezcan varias veces en los
documentos.
4. Busque el uso de mensajes y gráficos significativos que se publiquen en áreas comunes o en páginas Web.
5. Reconozca un sentido del humor, si es que lo hay.
El proceso de examinar documentos en busca de metáforas clave o de guía se lleva a cabo debido a que el
lenguaje da forma al comportamiento; por ende, las metáforas que empleamos son imprescindibles. Por ejem-
plo, una organización que habla sobre los empleados como “parte de una gran máquina” o “los engranes de una
rueda” podría estar adoptando un punto de vista orientado a la mecánica. Observe que la metáfora de guía en el
memo de la figura 5.6 es: “Somos una gran familia feliz”. El analista puede usar esta información para predecir
los tipos de metáforas que serán persuasivas en la organización. En definitiva, si un departamento está peleando
con otro, puede ser imposible obtener cooperación en un proyecto de sistemas a menos que se resuelvan las polí-
ticas en forma satisfactoria. El proceso de evaluar el sentido del humor provee una forma fácil y rápida de medir
muchas variables de HCI, interpersonales y organizacionales, incluyendo la subcultura a la que pertenece una
persona y el tipo de moral existente.
MEMOS Además de los cinco lineamientos anteriores, el analista también debe considerar quién envía los
memos y quién los recibe. Por lo general, en una organización, la mayor parte de la información fluye hacia
abajo y en sentido horizontal, en vez de hacerlo hacia arriba, por lo que se envían muchos mensajes por medio
MEMO
Para: Personal nocturno del centro de soporte
De: S. Leep, gerente del turno nocturno
Fecha: 15/2/2010
Asunto: Fiesta de presentación hoy en la noche
Es un placer dar la bienvenida a dos nuevos miembros del
personal del centro de soporte 11-7: Twyla Tine y Al Knight.
Estoy seguro de que disfrutarán su trabajo aquí. Estar juntos
en altas horas de la madrugada nos hace sentir como una
gran familia feliz. Recuerden que para sus descansos en la
noche algunos de los muchachos trajeron comida. Pueden
servirse lo que quieran de lo que tenemos en el salón de
descanso; bienvenidos al clan, Twyla y Al.
FIGURA 5.6
El análisis de los memos ayuda a
conocer las metáforas que guían el
pensamiento de la organización.www.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 141
de los sistemas de correo electrónico a grupos de trabajo e individuos. Los memos revelan un diálogo activo y
continuo en la organización. El análisis del contenido de los memos le proveerá una clara idea de los valores,
posturas y creencias de los miembros de la organización.
ANUNCIOS O PANCARTAS EN TABLEROS DE ANUNCIOS O EN ÁREAS DE TABAJO Aunque los anuncios pueden
parecer secundarios en comparación con lo que pasa en la organización, sirven como refuerzos sutiles de valores
para quienes los leen. Los lemas como “Calidad por siempre” o “La seguridad es primero” dan al analista una
idea de la cultura oficial de la organización.
SITIOS WEB CORPORATIVOS El analista también debe examinar los sitios Web que se utilizan para el comercio
de negocio a consumidor (B2C), así como los que se utilizan para las transacciones de negocio a negocio
(B2B). Examine el contenido de las metáforas, el humor, el uso de las características de diseño (color, gráficos,
animación e hipervínculos), además del significado y la claridad de los mensajes que se proporcionen. Piense en
el sitio Web desde tres perspectivas distintas: técnica, estética y gerencial. ¿Hay discrepancias entre los objetivos
establecidos de la organización y lo que se presenta al espectador? ¿Qué grado de personalización hay disponible en el
sitio Web para cada usuario? ¿Qué tanto se puede personalizar el sitio Web? Si no va a diseñar sitios de comercio
electrónico para la organización, ¿en qué afecta lo que usted ve en su sitio o sitios Web a los sistemas que está
investigando? Recuerde tomar notas del nivel de interactividad del sitio o sitios Web, la accesibilidad de los
mensajes y el nivel de seguridad.
MANUALES Los manuales de la organización son otros documentos cualitativos que el analista debe examinar.
Entre éstos se incluyen los manuales para los procedimientos de operación del equipo de cómputo y los manuales
en línea. Hay que analizar los manuales con base en los cinco lineamientos mencionados anteriormente. Recuerde
que los manuales presentan lo “ideal”, la forma en que se espera que se comporten las máquinas y las personas.
Es importante recordar que raras veces se mantienen actualizados los manuales impresos y, de hecho, algunas
veces quedan relegados en alguna repisa.
MANUALES DE POLÍTICAS El último tipo de documento cualitativo que consideraremos es el manual de políticas.
Aunque por lo general estos documentos abarcan amplias áreas de comportamiento de los empleados y la
empresa, usted se debe enfocar principalmente en aquellos que traten sobre las políticas relacionadas con los
servicios de cómputo, su uso, acceso, seguridad y cuotas. Al examinar las políticas, el analista de sistemas puede
obtener una buena idea de los valores, posturas y creencias que guían a la empresa.
E X P E R I E N C I A D E H Y P E R C A S E ® 5 . 1
“N os complace que usted considere a MRE un lugar intere-
sante para trabajar como consultor. De acuerdo con ciertos rumo-
res, usted ha estado ocupado explorando la oficina central. Sé que
hay mucho qué ver. Es difícil para nosotros llevar cuentas de todo.
Algo de lo que nos hemos asegurado a través de los años es tratar
de usar los métodos en los que creemos. ¿Ha visto alguno de
nuestros informes? ¿Qué hay sobre los datos que se recolectaron
en uno de los cuestionarios de Snowden? Él parece estar a favor
de los cuestionarios por encima de cualquier otro método. Algu-
nas personas le guardan rencor, pero creo que usted puede apren-
der mucho de los resultados. Algunas personas han sido buenas
a la hora de cooperar en estos proyectos. ¿Ya conoció a Kathy
Blandford?”
Preguntas de HYPERCASE
1. Utilice las pistas del caso para evaluar la experiencia de
cómputo de la Unidad de capacitación (Training Unit) y
los sentimientos de su personal en cuanto al PSRS. ¿Cuál
cree usted que sea el consenso en la Unidad de
Capacitación en cuanto al sistema de rastreo de proyectos
computarizado?
2. ¿Qué informes y declaraciones genera la Unidad de
capacitación durante el desarrollo del proyecto? Haga una
lista de cada una con una breve descripción.
2. De acuerdo con los resultados de las entrevistas, ¿cuáles son
los problemas con el sistema de rastreo de proyectos actual
en la Unidad de capacitación?
3. Describa el “conflicto de administración de proyectos” en
MRE. ¿Quién está involucrado? ¿Por qué hay un conflicto?
4. ¿Cómo lleva la Unidad de sistemas administrativos
(Management Systems Unit) el registro del progreso del
proyecto? Describa con brevedad el método o sistema.www.xlibros.com

142 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
OBSERVACIÓN DEL COMPORTAMIENTO DEL ENCARGADO DE TOMAR
DECISIONES
Observar a los encargados de tomar decisiones, su entorno físico y su interacción con el entorno físico y ergonó-
mico es un importante método discreto para el analista de sistemas. Mediante la observación de las actividades
de los encargados de tomar decisiones, el analista busca obtener una comprensión de lo que se lleva a cabo en
realidad, no sólo de lo que está documentado o explicado. Por medio de esta observación, el analista trata de ver
de primera mano las relaciones que existen entre los encargados de tomar decisiones y los demás miembros de la
organización, y al considerar además sus interacciones con las tecnologías también puede obtener pistas impor-
tantes relacionadas con cuestiones de HCI, como qué tan bien se adapta el sistema al usuario.
Observación de las actividades de toma de decisiones de un gerente común
La jornada de trabajo de un gerente se dice es una serie de interrupciones limitadas por breves ráfagas de trabajo.
En otras palabras, determinar lo que un gerente “hace” es una proposición resbalosa, incluso bajo las mejores
circunstancias. Para que el analista de sistemas pueda comprender adecuadamente la manera en que los gerentes
caracterizan su trabajo, se utilizan entrevistas interactivas y cuestionarios. Sin embargo, la observación permite al
analista ver de primera mano la forma en que los gerentes recopilan, procesan, comparten y utilizan la informa-
ción y la tecnología para llevar a cabo su trabajo.
Aunque es posible describir y documentar cómo toman decisiones los gerentes mediante el uso de cuadros
y flechas, lo que describiremos principalmente es a los humanos y sus actividades. Por lo tanto, sugerimos que
los analistas de sistemas utilicen una metodología más humanista para describir lo que hacen los gerentes.
A este método se le conoce como guión (playscript) del analista. Con esta técnica, el “actor” es el encargado
de tomar decisiones y a quien observamos cómo “actúa” o toma las decisiones. Al momento de establecer un
guión, el actor aparece en una lista en la columna izquierda y todas sus acciones se listan en la columna dere-
cha, como se muestra en la figura 5.7. Todas las actividades se registran con verbos; así, el encargado de las
decisiones se podría describir siempre llevando a cabo una actividad: “habla”, “muestrea”, “corresponde” y
“decide”.
El guión es un método organizado y sistemático que exige al analista ser capaz de comprender y articular la
acción que realiza cada uno de los encargados de tomar decisiones a los que se está observando. En un momento
dado, este método ayuda al analista de sistemas a determinar qué información se requiere para las decisiones im-
portantes o frecuentes que realizan las personas a las que observa. Así, del ejemplo del gerente de aseguramiento
de calidad en el guión, podemos ver con claridad que incluso cuando esta persona encargada de tomar decisiones
se encuentra en el nivel gerencial medio, de todas formas requiere una buena cantidad de información externa
para realizar las actividades requeridas de este trabajo específico.
OBSERVACIÓN DEL ENTORNO FÍSICO
Observar las actividades de los encargados de las decisiones es sólo una forma de evaluar sus requerimientos
de información. Al observar el entorno físico donde trabajan estas personas también podemos obtener muchos
detalles sobre sus requerimientos humanos de información. La mayoría de las veces, este proceso de informa-
ción implica examinar de manera sistemática sus oficinas y sus interacciones con la tecnología, ya que con
ambas suelen establecer una relación de influencia mutua. Muchas cuestiones de HCI se pueden identificar
por medio de la observación estructurada y se pueden conformar con otras técnicas, como las entrevistas o
cuestionarios.
Observación estructurada del entorno (STROBE)
Algunas veces, los críticos de cine utilizan una forma estructurada de crítica, conocida como análisis de puesta
en escena (mise-en-scène) para evaluar de manera sistemática lo que hay en una sola toma de la película. Anali-
zan la edición, el ángulo de la cámara, la decoración del set, los actores y sus vestimentas para averiguar cómo
dan forma al significado de la película según las intenciones del director. Algunas veces la mise-en-scène de una
película contradice lo que se dice en el diálogo. Para el análisis de los requerimientos de información, el analista
de sistemas suele proceder de manera análoga. A menudo es posible observar los detalles específicos de los alre-
dedores que confirmarán o negarán la narrativa organizacional (también conocida como “historias” o “diálogo”)
que se encuentra a través de las entrevistas o cuestionarios.
Al método para la observación estructurada del entorno (STRuctured OBservation of the Environment) se
le conoce como STROBE, por sus siglas en inglés. Para aplicar el método STROBE con éxito, el analista tienewww.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 143
que observar de manera explícita siete elementos concretos que se encuentran comúnmente en las oficinas. En la
figura 5.8 se muestran los siete elementos observables y algunas de las preguntas clave que pueden surgir. Estos
elementos pueden revelar mucho sobre la forma en que un encargado de tomar decisiones recopila, procesa, al-
macena y comparte información, así como sobre su credibilidad en el lugar de trabajo.
UBICACIÓN DE LA OFICINA Uno de los primeros elementos que debe observar un analista de sistemas es la ubica-
ción de la oficina de un encargado de tomar decisiones con respecto a las demás oficinas. Las oficinas accesibles
tienden a incrementar la frecuencia de interacción y los mensajes informales, mientras que las oficinas
inaccesibles tienden a reducir la frecuencia de interacción y aumentan los mensajes orientados a tareas. Las
oficinas distribuidas a lo largo del perímetro del edificio por lo general ocasionan que se retenga un informe o
memo en una de las oficinas, mientras que los conglomerados de oficinas fomentan la difusión de información.
También es probable que las personas cuyas oficinas estén separadas de los demás tengan la tendencia de ver a la
Análisis de
guión
Empresa: Solid Steel Shelving
Analista: L. Bracket
Escenario: Aseguramiento de calidad
Fecha: 1/3/2010
Gerente de aseguramiento
de calidad
Pide al supervisor de piso de la tienda el
informe diario de producción
Supervisor de piso
de la tienda
Imprime el informe diario de producción
computarizado
Habla sobre los problemas recurrentes en las
tiradas de producción con el gerente de
aseguramiento de calidad (QA)
Gerente de aseguramiento
de calidad
Lee el informe de producción
Compara el informe actual con los demás
informes de la misma semana
Introduce los datos de la tirada de producción
diaria en el modelo de QA en la computadora
Observa los resultados en pantalla del modelo
de QA
Llama a los proveedores de acero para hablar
sobre las desviaciones de los estándares de
calidad
Supervisor de piso
de la tienda
Asiste a la reunión sobre las nuevas
especificaciones de calidad con el gerente de
aseguramiento de calidad y el vicepresidente
de producción
Gerente de aseguramiento
de calidad
Hace un borrador de la carta para informar a
los proveedores sobre las nuevas especificaciones
de calidad acordadas en la reunión
Envía el borrador al vicepresidente vía correo
electrónico
Vicepresidente de
producción
Lee el borrador de la carta
Devuelve las correcciones y comentarios vía
correo electrónicoGerente de aseguramiento
de calidad
Lee la carta corregida en el correo electrónico
Vuelve a escribir la carta para reflejar los
cambios
Encargado de tomar
decisiones (actor) Actividad relacionada con la información (guión)
FIGURA 5.7
Una página de muestra del guión
del analista, en la que se describe
el proceso de toma de decisiones.www.xlibros.com

144 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
organización de una manera distinta y, por ende, se aparten de los demás miembros de la organización en cuanto
a sus objetivos.
COLOCACIÓN DEL ESCRITORIO La colocación de un escritorio en la oficina puede ofrecer pistas en cuanto a la
forma en que el encargado de tomar decisiones ejerce su poder. Los ejecutivos que encierran a un visitante en
un espacio estrecho con la espalda del visitante dando a la pared mientras se permiten a sí mismos un amplio
espacio, se colocan por sí solos en la más alta posición de poder posible. Es probable que un ejecutivo que coloca
su escritorio de cara a la pared con una silla a un lado para el visitante fomente la participación e intercambios
equitativos de información. El analista de sistemas debe observar la disposición de los muebles de la oficina y
en especial la colocación del escritorio. La figura 5.9 muestra un ejemplo de la colocación de un escritorio, así
como muchos de los otros elementos de STROBE, como los accesorios, el equipo de oficina estacionario, la
iluminación, el color y las fuentes externas de información.
Ubicación de la oficina
¿Quién tiene la oficina de la esquina? ¿Están
dispersos en pisos separados los encargados de
tomar decisiones?
Colocación del escritorio ¿Acaso la colocación del escritorio fomenta la
comunicación? ¿Demuestra poder?
Equipo estacionario
¿Prefiere el encargado de tomar decisiones recopilar
y almacenar la información en forma personal? ¿Es
grande o pequeña el área de almacenamiento?
Accesorios
¿Hay evidencia de que el encargado de tomar
decisiones utiliza una PC, un teléfono inteligente o
una computadora tipo tableta en la oficina?
Fuentes externas de información
Iluminación y colores de la oficina
Ropa que utilizan los
encargados de tomar decisiones
¿Obtiene el encargado de tomar decisiones mucha
información de las fuentes externas, como las
publicaciones especializadas o la Web?
¿Está preparada la iluminación para realizar trabajo
detallado o es más apropiada para una comunicación
casual? ¿Son los colores cálidos y atractivos?
¿Muestra autoridad el encargado de tomar decisiones
al usar trajes conservadores? ¿Se requiere que los
empleados usen uniformes?
Preguntas que un analista podría investigarElemento observable
FIGURA 5.8
Siete elementos concretos
observables de STROBE y
ejemplos de preguntas que tal vez
un analista quiera hacer.
*
SEKR
Discos CD-RW Iluminación
fluorescente
Publicaciones especializadas
en el librero
PC en el
escritorio
Archivero
FIGURA 5.9
Observe la oficina del encargado
de tomar decisiones para obtener
pistas concernientes a su
almacenamiento personal,
procesamiento y difusión de la
información.www.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 145
EQUIPO DE OFICINA ESTACIONARIO Los archiveros, libreros y demás equipo grande para
almacenar artículos se incluyen en la categoría de equipo de oficina estacionario. Si no hay tal
equipo, es probable que el encargado de tomar decisiones almacene muy pocos elementos de
información personalmente. Si hay mucho equipo de este tipo, es posible que el encargado
de tomar decisiones almacene y valore mucha información.
ACCESORIOS El término accesorios (props en inglés, una abreviación del término propiedades
utilizado en el teatro/cine) se refiere a todo el equipo pequeño empleado para procesar
O P O R T U N I D A D D E C O N S U L T O R Í A 5 . 3
No confíes en su autoestima
o no todo se refleja en un espejo
“No quiero poder aquí”, objeta el Dr. Drew Charles, director
médico del banco de sangre regional, donde el grupo de sistemas
que usted dirige acaba de empezar un proyecto. “Estoy hasta el
cuello de trabajo tratando de mantener informados a los médicos
regionales para que sigan las buenas prácticas de los bancos de
sangre”, dice, cerrando los ojos debido a la brillante luz solar que
entra en su oficina. Apaga la pantalla conectada a su PC y pone su
atención en usted y en la entrevista.
El Dr. Charles está vestido en un conservador traje oscuro de
lana y utiliza una corbata de seda con rayas rojas. Continúa: “De
hecho, no tomo decisiones. Estoy aquí sólo en plan de apoyo posi-
tivo”. Saca el cuadro de la organización que se muestra en la figura
5.C1 para demostrar lo que dice. “Es tan claro como una fractura.
El administrador en jefe es el experto en todas las cuestiones admi-
nistrativas. Yo sólo soy el consultor médico”.
La oficina del Dr. Charles está atestada no sólo de publicacio-
nes médicas como Transfusion, sino también con copias amarillen-
tas de viejas revistas BYTE y las ediciones más recientes de Business
Week. Cada revista de Business Week está abierta en una página
distinta, como si el doctor estuviera en el proceso de devorar cada
bocado de información. Sin embargo, las publicaciones médicas
desbordadas no están almacenadas meticulosamente en libreros
metálicos, como podría esperar. En crudo contraste con el relu-
ciente equipo nuevo que vio en uso en las salas de donantes, las
publicaciones médicas están apiladas en enormes columnas en una
vieja cama para donadores de sangre que se retiró desde hace mu-
cho de su uso original.
A continuación usted decide entrevistar al administrador en
jefe, Craig Bunker, a quien el Dr. Charles aludió. Quince minutos
después del inicio programado de su cita, la secretaria de Bunkers,
Dawn Upshaw, finalmente le permite entrar a su oficina. Bunker,
que acaba de terminar una conversación telefónica, está vestido en
un saco sport color azul claro, pantalones de cuadros, camisa color
azul claro y una corbata. “¿Cómo está? He estado investigando para
ver cómo anda todo”, dice Bunker a modo de presentación. Es so-
ciable y muy amigable.
Al observar el cuarto, usted detecta que no hay archiveros ni
una PC como la que utiliza el Dr. Charles. Hay muchas fotografías
de la familia de Craig Bunker, pero el único artículo que se asemeja
a un libro o revista es el boletín informativo del centro, Bloodline.
Al empezar la entrevista formal, Bunker se enfrasca en historias
sobre el Banco de sangre de Pennslvania, donde ocupó el puesto de
asistente administrador hace seis años.
Por último, usted baja por las escaleras al húmedo sótano de la
mansión Heath Lambert. Las unidades móviles acaban de regresar
de llevar la sangre procesada a los hospitales del área. Usted decide
hablar con Sang Kim, el conductor de una de ellas; con Jenny
McLaughlin, el gerente de distribución; y con Roberta Martin, una
técnica del laboratorio que trabaja en el turno nocturno.
Roberta empieza: “No sé qué haríamos sin el doctor”. Sang con-
tribuye a la conversación y agrega: “Es cierto, nos ayudó a idear un
mejor itinerario de conducción el año pasado”.
Jenny añade: “El Dr. Charles es imprescindible para establecer los
niveles de inventario de cada hospital y, si no fuera por él, no tendría-
mos nuestro nuevo software ni mucho menos nuestra nueva red”.
Como uno de los miembros del equipo de análisis de sistemas
asignado al proyecto del banco de sangre, desarrolle una lista de
verificación de anécdotas mediante el uso del método STROBE
para interpretar de manera sistemática las observaciones que hizo
sobre las oficinas del Dr. Charles y de Craig Bunker. Considere
cualquier discrepancia entre la vestimenta de un encargado de to-
mar decisiones, sus declaraciones y lo que dicen los demás sobre él;
entre la ubicación de su oficina y lo que se expone; y entre el equipo
de oficina las políticas establecidas. Además, sugiera en un párrafo
las posibles entrevistas de seguimiento y las observaciones para
ayudar a resolver cualquier pregunta sin contestar.
Recolección
de sangre
Distribución
de sangre Contabilidad Sistemas
computacionales Secretarial Laboratorio Enfermería Investigación
Director
médico
Director
administrativo
FIGURA 5.C1
Cuadro organizacional del centro de sangre regional.www.xlibros.com

146 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
información, incluyendo teléfonos inteligentes, calculadoras, PC, plumas, lápices y reglas. La presencia de
equipos de bolsillo, calculadoras y PC en la oficina del encargado de tomar decisiones sugiere que es más
probable que los utilice en forma personal que alguien que deba salir de la oficina para usarlos.
FUENTES EXTERNAS DE INFORMACIÓN Un analista de sistemas necesita saber el tipo de información que utiliza
el encargado de tomar decisiones. Al observar el tipo de publicaciones almacenadas en su oficina es posible
averiguar si el encargado de tomar decisiones busca información externa (la que encuentra en publicaciones
especializadas, artículos de noticias sobre otras empresas en la industria, etc.) o si confía más en la información
interna (informes de la empresa, correspondencia entre oficinas, manuales de políticas). El analista también debe
observar si el encargado de tomar decisiones prefiere obtener información externa a través de Web.
ILUMINACIÓN Y COLORES DE LA OFICINA La iluminación y el color desempeñan un papel importante en la
forma en que el encargado de tomar decisiones recopila información. Una oficina con iluminación cálida e
incandescente indica la tendencia hacia una comunicación más personal. Un ejecutivo en una oficina con
iluminación cálida recopilará más información de manera informal, mientras que algún otro miembro de la
organización que trabaje en una oficina con mucha iluminación y colores fuertes tal vez recopile información por
medios más formales, como memos e informes oficiales.
VESTIMENTA DE LOS ENCARGADOS DE LAS DECISIONES Mucho se ha escrito sobre la vestimenta que utilizan
los ejecutivos y demás personas con autoridad. El analista de sistemas puede obtener un entendimiento de la
credibilidad que exhiben los gerentes en la organización al observar la ropa que utilizan en el trabajo. El traje de
dos piezas para un hombre, o con falda para una mujer, representa la máxima autoridad, de acuerdo con algunos
investigadores que han estudiado las percepciones de la apariencia de los ejecutivos. Cuando los líderes visten
ropa casual pueden dar cabida a un proceso de toma de decisiones más participativo, pero dicha vestimenta a
menudo provoca cierta pérdida de credibilidad en la organización, si la cultura predominante valora la vestimenta
tradicional y conservadora.
Mediante el uso del método STROBE, el analista de sistemas puede obtener una mejor comprensión de la
forma en que los gerentes recopilan, procesan, almacenan y utilizan la información. En la figura 5.10 se muestra
un resumen de las características que exhiben los encargados de tomar decisiones y los correspondientes elemen-
tos observables.
Aplicación del método STROBE
Una forma de implementar el método STROBE es mediante el uso de una lista de verificación de anécdotas con
símbolos de taquigrafía representativos. Esta forma de aplicar el método STROBE fue útil para averiguar los
requerimientos de información para cuatro personas encargadas de tomar decisiones clave en una franquicia de
tiendas de ropa.
Como se muestra en la figura 5.11, los analistas de sistemas utilizaron cinco símbolos de taquigrafía para
evaluar cómo se comparaba la observación de los elementos STROBE con la narrativa organizacional generada
por medio de las entrevistas. Los cinco símbolos son:
1. Una marca de verificación indica que se confirmó la narrativa.
2. Una “X” indica que se invierte la narrativa.
Recopila información de manera informal
Busca información fuera de la organización
Procesa los datos en forma personal
Almacena información en forma personal
Ejerce poder en la toma de decisiones
Exhibe credibilidad en la toma de decisiones
Comparte información con los demás
Iluminación incandescente y colores cálidos
Había publicaciones especializadas en la oficina
Había PC o computadoras tipo tableta en la oficina
Había equipo/archivos en la oficina
La ubicación del escritorio denota poder
Usa ropa que refleja autoridad
Oficina con fácil acceso
Elementos correspondientes en
el entorno físico
Características de los encargados
de tomar decisiones
FIGURA 5.10
Un resumen de las características
de los encargados de tomar
decisiones, las cuales
corresponden a los elementos
observables en el entorno físico.www.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 147
3. Un óvalo o símbolo en forma de ojo sirve como pista para que el analista de sistemas busque más detalles.
4. Un cuadrado indica que la observación de los elementos STROBE modifica la narrativa.
5. Un círculo indica que la narrativa se complementa con lo que se observó.
Al implementar el método STROBE de esta forma, el primer paso es anotar los temas clave de la or-
ganización que surjan de las entrevistas. Después se observan y registran los elementos de STROBE. Más
adelante, al comparar la narrativa y las observaciones, se utiliza uno de los cinco símbolos apropiados para
caracterizar la relación. Así, el analista crea una tabla que primero documenta y después ayuda a analizar las
observaciones.
A T R A C T I V O D E L A M A C
Recolectar datos en forma discreta parece algo sencillo, hasta que nos damos cuenta de que debemos organizar, alma-
cenar y recuperar todos los datos recolectados para llevar a cabo el análisis. La solución más simple es un paquete de
software llamado Yojimbo de la compañía Bare Bones. Es económico y fácil de usar. Sólo hay que arrastrar los elemen-
tos que deseamos recolectar hacia Yojimbo y buscarlos después. Una metodología más estructurada sería usar una
aplicación como DEVONthink Professional Office. La metáfora de una oficina es un poco ambiciosa, ya que usar esta
aplicación es como arrojar todo tipo de datos en el cajón de un escritorio y después averiguar cómo organizarlo. DE-
VONthink acepta archivos de Microsoft Word, Excel y PowerPoint, así como cualquier objeto de iWork. Puede llevar
el registro de sitios favoritos y páginas Web, imágenes y archivos PDF. Un lector OCR integrado ayuda a introducir
páginas en forma directa.
Cuando llega el momento de acceder a la información, DEVONthink puede ayudar al analista de sistemas a reali-
zar búsquedas, clasificar y mostrar relaciones entre los elementos gracias a la inteligencia artificial. DEVONthink no
ayuda a un analista a determinar el tamaño de las muestras o a llevar la cuenta de los errores, pero sí ayuda a recolectar,
almacenar, recuperar, usar y compartir la información recopilada por el analista.
FIGURA 5.MAC
DEVONthink Professional Office de DEVONtechnologies.www.xlibros.com

148 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Lista de anécdotas con símbolos para aplicar STROBE
Narrativa descrita por los
miembros de la organización
Ubicación de
oficina y equipo
Iluminación, color y
elementos gráficos
de la oficina
Vestimenta del
encargado de tomar
decisiones
Clave
Confirma la narrativa
Niega o invierte la narrativa
Pista para buscar más detalles
Modifica la narrativa
Complementa la narrativa
La información fluye de manera
activa en todos los niveles.
Adams dice: “Yo calculo los
porcentajes por mi cuenta”.
Vinnie dice: “Me gusta estudiar
sobre estas cosas”.
Ed dice: “La mano derecha no
siempre sabe lo que está haciendo
la mano izquierda”.
Adams dice: “Nuestra empresa no
pasa por muchos cambios”.
El personal de operaciones trabaja
toda la noche algunas veces.
Vinnie dice: “Hacemos las cosas
según lo que quiera el Sr. Adams”.
Julie dice: “Algunas veces parece
como si a Stanley no le importara”.
FIGURA 5.11
Lista anecdótica con símbolos,
para la implementación de
STROBE.
En este capítulo conocimos los métodos discretos para recopi-
lar información: el muestreo, la investigación de datos cualita-
tivos y cuantitativos en formularios actuales y archivados, y la
observación de las actividades del encargado de las decisiones
por medio del guión del analista, así como la observación del
entorno físico del encargado de las decisiones mediante el uso
de STROBE.
Al proceso de seleccionar en forma sistemática los ele-
mentos representativos de una población se le conoce como
muestreo. El propósito del muestreo es seleccionar y estudiar
documentos como facturas, informes de ventas y memos, o
tal vez seleccionar y entrevistar, repartir encuestas u observar
miembros de la organización. El muestreo puede reducir los
costos, agilizar el proceso de recopilación de datos, mejorar
la efectividad del estudio y reducir la predisposición en el
mismo.
Un analista de sistemas debe seguir cuatro pasos para dise-
ñar una buena muestra: determinar la población, decidir sobre
el tipo de muestra, calcular el tamaño de la misma y planear los
datos que es necesario recolectar o describir.
RESUMENwww.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 149
E X P E R I E N C I A D E H Y P E R C A S E ® 5 . 2
“Estamos orgullosos de nuestro edificio aquí en Tennessee. De
hecho, pedimos a la firma arquitectónica I. M. Paid que usara el
mismo tema para mezclarnos con el paisaje local y, al mismo
tiempo, identificarnos con nuestros clientes en todas las sucursales.
Recibimos muchas personas que entran sólo para admirar el edifi-
cio, una vez que se dan cuenta dónde se ubica exactamente. De
hecho, para los estándares de Tennessee, recibimos tantos visitan-
tes, ¡que bien podríamos compararnos con las pirámides! Bueno,
usted podrá averiguarlo por su cuenta a medida que lo recorra. El
Atrio este (East Atrium) es mi lugar favorito: entra mucha luz a
través del enorme tragaluz del techo. Además siempre me ha fasci-
nado el hecho de que el edificio y su mobiliario podrían contar una
historia muy distinta a la que cuentan sus ocupantes”.
“Algunas veces los empleados se quejan de que todas las ofici-
nas se ven iguales. Pero las salas públicas son espectaculares. Incluso
el comedor es atractivo. La mayoría de las personas no pueden decir
lo mismo de las cafeterías de su lugar de trabajo. De todas formas
puede observar que todos personalizamos nuestras oficinas. Así que,
aunque éstas fueran iguales, las personalidades de sus ocupantes se
adueñan de ellas después de un tiempo de ocuparlas. ¿Qué ha visto
usted? ¿Hubo algo que lo sorprendiera hasta ahora?”.
Preguntas de HYPERCASE
1. Use el método STROBE para comparar y contrastar las
oficinas de Evans y Ketcham. ¿A qué conclusión puede llegar
con sus observaciones de la manera en que cada persona
utiliza la tecnología de la información? ¿Qué tan compatibles
parecen ser Evans y Ketcham en términos de los sistemas que
utilizan? ¿Qué otras pistas en cuanto al almacenamiento, al
uso y a la difusión de la información puede descubrir después
de haber observado sus oficinas?
2. Examine con cuidado la oficina de Kathy Blandford. Use el
método STROBE para confirmar, invertir o negar lo que supo
durante su entrevista con ella. Haga una lista de todo lo que
encuentre sobre la Srita. Blandford después de observar su
oficina, que no haya averiguado en la entrevista.
3. Examine con cuidado el contenido del área de recepción de
MRE mediante el método STROBE. ¿Qué cosas puede
inferir sobre la organización? Elabore una lista. ¿Qué
preguntas le gustaría hacer en las entrevistas después de
haber observado el área de recepción? Haga una lista de las
personas a las que le gustaría entrevistar y las preguntas que
haría a cada una de ellas.
FIGURA 5.HC1
Hay pistas ocultas en HyperCase. Use el método STROBE para descubrirlas.
Los tipos de muestras útiles para un analista de siste-
mas son: de conveniencia, intencionadas, simples aleatorias y
complejas aleatorias. El último tipo incluye las subcategorías
de muestreo sistemático y muestreo estratificado. Hay varios
lineamientos a seguir para determinar el tamaño de las mues-
tras.www.xlibros.com

150 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
PALABRAS CLAVE Y FRASES
accesorios (dispositivos de bolsillo y PC)
colocación del escritorio
comercio de negocio a consumidor (B2C)
comercio de negocio a negocio (B2B)
equipo de oficina estacionario
fuentes externas de información
guión del analista
iluminación y colores de la oficina
muestra compleja aleatoria
muestra de conveniencia
muestra intencionada
muestra simple aleatoria
muestreo
muestreo de conglomerado
muestreo estratificado
muestreo sistemático
nivel de confianza
observación sistemática
población de muestra
sitios Web corporativos
STROBE
ubicación de la oficina
vestimenta utilizada por los encargados de tomar decisiones
PREGUNTAS DE REPASO
1. Defina lo que significa muestreo.
2. Mencione cuatro razones por las que sería conveniente para el analista de sistemas muestrear datos o seleccionar
personas representativas para las entrevistas.
3. ¿Cuáles son los cuatro pasos a seguir para diseñar una buena muestra?
4. Mencione las tres metodologías para el muestreo complejo aleatorio.
5. Defina lo que significa estratificación de las muestras.
6. ¿Qué efecto sobre el tamaño de la muestra se produce al usar un mayor nivel de confianza a la hora de muestrear los
datos de los atributos?
7. ¿Cuál es la variable primordial que determina a cuántas personas debe el analista de sistemas entrevistar a profundidad?
8. ¿Qué información sobre el encargado de tomar decisiones busca obtener el analista a partir de la observación?
9. Mencione cinco pasos para ayudar al analista a observar las actividades comunes del encargado de tomar decisiones.
10. En la técnica conocida como guión del analista, ¿quién es el actor?
11. En el guión del analista, ¿qué información sobre los gerentes se registra en la columna de la derecha?
12. Teniendo en cuenta que la idea de STROBE provino originalmente del mundo cinematográfico, ¿a qué se asemeja el
papel del analista de sistemas?
13. Haga una lista de los siete elementos concretos del entorno físico del encargado de tomar decisiones que el analista de
sistemas puede observar mediante el uso de STROBE.
PROBLEMAS
1. A Cheryl Stake le preocupa que se estén llenando demasiados formularios de manera incorrecta. Ella cree que
aproximadamente un 8 por ciento de los formularios tienen errores.
a. ¿Qué tan grande debe ser el tamaño de muestra que utilice la Srita. Stake para estar un 99 por ciento segura de que
estará dentro del 0.02?
b. ¿Qué tan grande debe ser el tamaño de muestra que utilice la Srita. Stake para estar un 90 por ciento segura de que
estará dentro del 0.02?
c. Explique la diferencia entre las partes a y b.
Los analistas de sistemas necesitan investigar los datos y
formularios actuales y archivados, los cuales revelan dónde
ha estado la organización y hacia dónde creen sus miembros
que se dirige. Hay que analizar tanto los documentos cuantita-
tivos como los cualitativos. Debido a que los documentos son
mensajes persuasivos, debe tomar en cuenta que modificarlos
puede también cambiar a la organización.
Los analistas utilizan la observación como una técnica de
recopilación de información; por medio de ella llegan a enten-
der lo que en realidad ocurre cuando los usuarios interactúan
con la tecnología de la información. Una manera de describir la
forma en que se comportan los encargados de tomar decisiones
es mediante el uso de un guión del analista, en el que se docu-
menta cada una de las actividades de los principales actores.
Además de observar el comportamiento del encargado de
las decisiones, el analista de sistemas debe observar su entorno
en busca de pistas importantes que le indiquen qué tan bien se
adapta el sistema al usuario. Uno de los métodos para ello es la
Observación estructurada del entorno (STROBE). Un analista
de sistemas utiliza el método STROBE de la misma forma en
que un crítico de cine utiliza un método conocido como análisis
de puesta en escena (mise-en-scène) para analizar una toma en
una película.
Es posible observar e interpretar varios elementos concre-
tos en el entorno del encargado de tomar decisiones: 1) ubi-
cación de la oficina, 2) colocación de su escritorio, 3) equipo
de oficina estacionario, 4) accesorios como dispositivos de
bolsillo y PC, 5) fuentes externas de información como pu-
blicaciones especializadas y el uso de Web, 6) iluminación y
colores de la oficina y 7) vestimenta que utiliza el encargado
de tomar decisiones. Se puede utilizar el método STROBE para
comprender mejor la verdadera forma en que los encargados de
tomar decisiones recopilan, procesan, almacenan y comparten
la información para poder llevar a cabo su trabajo.www.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 151
d. Suponga que la Srita. Stake aceptará un nivel de confianza del 95 por ciento de que estará dentro del 0.02. ¿Cuál
deberá ser ahora el tamaño de la muestra de los formularios?
2. “Veo que tiene muchos papeles ahí. ¿Qué es todo eso?”, pregunta Betty Kant, jefa de la fuerza de trabajo de MIS que
constituye el grupo de enlace entre el grupo de sistemas que usted encabeza y la empresa Sawder’s Furniture Company.
Usted se encuentra lidiando con un gran paquete de papeles en el momento en que se prepara para salir del edificio.
“Bueno, tengo algunos estados de cuenta financieros, informes de producción de los últimos seis meses y algunos
informes de rendimiento que me dio Sharon sobre los objetivos y el rendimiento laboral durante los últimos seis meses”,
le contesta usted al tiempo que algunos de los papeles caen al piso. “¿Por qué?”
Betty toma los papeles que trae usted y los coloca en el escritorio más cercano. Después le responde: “Por que no
necesita toda esta basura. Está aquí para una cosa: hablar con nosotros, los usuarios. Apuesto a que nada de ese altero es
trascendente”.
a. La única forma de convencer a Betty de la importancia de cada documento es decirle lo que busca en cada uno.
Explique en un párrafo qué tipo de documento contribuye para que el analista de sistemas pueda entender el
funcionamiento de la empresa.
b. Mientras habla con Betty se da cuenta de que también necesita otros documentos cuantitativos. Haga una lista de
ellos.
3. Recientemente, usted obtuvo muestras de los mensajes de correo electrónico que se han enviado a varios gerentes de
nivel medio de Sawder’s Furniture Company, que distribuye muebles de aglomerado del tipo “hágalo usted mismo” en
todo el país. He aquí una que repite un mensaje que se encontró en varios memos más:
Para: Sid, Ernie, Carl
De: Imogene
Re: Provisiones de computadora/impresora
Fecha: Noviembre 10, 2009
Me han hecho saber que estoy en una guerra contra las solicitudes de provisiones de computadora e impresora (CD
grabables, tóner, papel, etc.) que están fuera de proporción en cuanto a lo que se había negociado con base en el
presupuesto actual. Como todos aquí somos buenos soldados, espero que acepten lo que su sargento de provisiones les
indique que sea lo normal. Por favor, no más “requisiciones a medianoche” para compensar la escasez en existencia.
Gracias por su lealtad, soldados; esto facilita la batalla para todos nosotros.
a. ¿Qué metáfora(s) se está(n) usando? Haga una lista de la metáfora dominante y otras frases que se relacionen con
ese tema.
b. Si encontró evidencia repetida de esta idea en otros mensajes de correo electrónico, ¿qué interpretación tendría? Use
un párrafo para explicar.
c. Describa en un párrafo la forma en que las personas en su grupo de análisis de sistemas pueden usar la información
de los mensajes de correo electrónico para dar forma a su proyecto de sistemas para Sawder’s.
d. En entrevistas con Sid, Ernie y Carl, no ha habido mención de problemas para obtener suficientes provisiones de
computadora e impresora. Describa en un párrafo por qué dichos problemas tal vez no surjan en las entrevistas y
hable sobre el valor de adicionalmente examinar los mensajes de correo electrónico y otros memos.
4. “He aquí el manual principal de políticas en el que hemos trabajado durante todos estos años para los usuarios del
sistema”, dice Al Bookbinder, al tiempo que sopla el polvo del manual y se lo entrega. Al se encarga de guardar los
documentos para el departamento de sistemas de Prechter and Gumbel, un gran fabricante de productos para el cuidado
de la salud y de belleza. “Todo lo que necesita saber cualquier usuario de cualquier parte del sistema está en lo que yo
llamo el Libro Azul. Es decir, está abarrotado de políticas. Es tan grande. Yo soy el único con un ejemplar completo.
Cuesta demasiado reproducirlo”. Usted agradece a Al y se lleva el manual. Al leerlo se asombra de su contenido. La
mayoría de las páginas empiezan con un mensaje tal como: “Esta página sustituye a la página 23.1 en el Vol. II del
manual. Deseche los insertos anteriores; no usar”.
a. Haga una lista de sus observaciones sobre la frecuencia de uso del Libro Azul.
b. ¿Qué tan amigables para los usuarios son las actualizaciones en el manual? Escriba un enunciado en el que explique
su respuesta.
c. Escriba un párrafo en el que comente sobre la sabiduría de tener todas las políticas importantes para todos los
usuarios del sistema en un solo libro.
d. Sugiera una solución que incorpore el uso de manuales de políticas en línea para algunos usuarios.
5. “Creo que podré recordar casi todo lo que él hace”, dice Ceci Awll. Ceci está a punto de entrevistar a Biff Welldon,
vicepresidente de planeación estratégica de OK Corral, una cadena de restaurantes de bisteces con 130 sucursales. “Es
decir, tengo buena memoria. De todas formas, creo que es mucho más importante escuchar lo que dice que observar lo
que hace”. Como miembro del equipo de analistas de sistemas que usted dirige, Ceci ha estado hablando con usted
sobre la conveniencia de anotar sus observaciones de la oficina de Biff y sus actividades durante la entrevista.
a. En un párrafo, persuada a Ceci de que no basta con escuchar en las entrevistas, sino que también es importante
observar y registrar esas observaciones.
b. Parece que Ceci ha aceptado su idea de que es importante la observación, pero aún no sabe cómo realizarla. Haga
una lista de elementos y comportamientos a observar, y en un enunciado junto a cada comportamiento indique el
tipo de información que Ceci debe obtener.www.xlibros.com

152 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
6. “Somos una empresa progresista, siempre buscando estar delante de la curva de energía. Probaremos cualquier cosa con
tal de que podamos adelantarnos a la competencia, y eso nos incluye a todos”, dice I. B. Daring, un ejecutivo de la
empresa Michigan Manufacturing (2M). Usted lo está entrevistando como un paso preliminar en un proyecto de
sistemas en el que sus subordinados han expresado interés. A medida que escucha a I. B., echa una ojeada en su oficina y
descubre que la mayor parte de la información que tiene almacenada en las repisas se puede clasificar como manuales de
procedimientos internos. Además observa que hay una PC en una mesa en la parte posterior de la oficina de I. B. La
pantalla está cubierta de polvo y los manuales apilados a un lado de la PC aún tienen la envoltura original. Aunque usted
sabe que 2M utiliza una intranet, no puede ver cables que entren o salgan de la PC de I.B. En la pared detrás del enorme
escritorio de caoba se aprecian cinco retratos al óleo, enmarcados, de los fundadores de 2M, todos agrupados alrededor
de una placa dorada que porta el lema de la corporación: “Asegúrese de estar en lo correcto y después, siga adelante”.
a. ¿Cuál es la narrativa organizacional o argumento según lo que describe I. B. Daring? Reformule con sus propias
palabras.
b. Haga una lista de los elementos de STROBE que haya observado durante su entrevista con I.B.
c. Escriba, al lado de cada elemento de STROBE que haya observado, un enunciado sobre cómo lo interpretaría.
d. Construya una tabla con el lema de la organización del lado inferior izquierdo de la página y los elementos de
STROBE en la parte superior. Use los símbolos de la aplicación de la “lista de anécdotas” de STROBE para indicar
la relación entre el argumento de la organización según lo descrito por I.B. y cada elemento que usted haya
observado (es decir, indique si cada elemento de STROBE confirma, invierte, lo obliga a buscar más detalles,
modifica o complementa la narrativa).
e. Con base en sus observaciones de STROBE y su entrevista, declare en un párrafo los problemas que puede anticipar
en cuanto a obtener un nuevo sistema aprobado por I.B. y los demás. En una oración o dos describa cómo hubiera
podido ser distinto su diagnóstico si sólo hubiera hablado con I.B. por teléfono, o si hubiera leído sus comentarios
escritos en una propuesta de sistemas.
PROYECTOS EN GRUPO
1. Suponga que su grupo servirá como equipo de análisis y diseño de sistemas en un proyecto diseñado para computarizar
o mejorar la computarización de todos los aspectos de negocios de una empresa de transportes estadounidense a nivel
nacional con una trayectoria de 15 años, conocida como Maverick Transport. Esta empresa se especializa en embarques
menores a un camión completo (LTL). Los empleados de la administración trabajan con base en la filosofía de justo a
tiempo (JIT), a partir de la cual han creado una sociedad en la que se incluye el emisor, el destinatario y el transportista
(Maverick Transport) para el propósito de transportar y entregar los materiales que se requieren justo a tiempo para
usarlos en la línea de producción. Maverick mantiene 626 camiones para transportar carga y cuenta con 45,000 pies
cuadrados de espacio de bodega, además de 21,000 pies cuadrados de espacio de oficina.
a. Desarrolle junto a los miembros de su grupo una lista de recursos de datos de archivo que se deban verificar al
analizar los requerimientos de información de Maverick.
b. Cuando la lista esté completa, idee un esquema de muestreo que permita a su grupo obtener una imagen clara de la
empresa sin tener que leer todos los documentos generados en su historial de 15 años.
2. Haga los arreglos para visitar una organización local que esté en expansión o que esté mejorando de alguna forma sus
sistemas de información. Para que su grupo pueda practicar los diversos métodos de observación descritos en este
capítulo, asigne uno de estos dos métodos a cada miembro del equipo: 1) desarrollar el guión del analista o 2) usar
STROBE. Es posible emplear muchas de estas estrategias durante las entrevistas de uno a uno, mientras que otras
requieren reuniones formales en la organización. Trate de cumplir con varios objetivos durante su visita a la
organización; prográmela a una hora apropiada que permita a todos los miembros del equipo probar su método de
observación asignado. Usar varios métodos como las entrevistas y la observación (la mayor parte de las veces al mismo
tiempo) es la única forma efectiva en costo de obtener una imagen verdadera y oportuna de los requerimientos de
información de la organización.
3. Los miembros de su grupo se deben reunir y discutir sobre sus hallazgos después de completar el proyecto 2. ¿Hubo
sorpresas? ¿La información recopilada por medio de la observación confirmó, invirtió o negó lo que se aprendió en las
entrevistas? ¿Hubo conflictos directos entre algunos de los hallazgos de los métodos de observación? Trabaje con su
grupo para desarrollar una lista de formas de lidiar con cualquier tipo de información desconcertante (por ejemplo,
mediante la realización de entrevistas de seguimiento).www.xlibros.com

CAPÍTULO 5 • RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS 153
BIBLIOGRAFÍA SELECCIONADA
Cooper, D. R. y P. S. Schindler. Business Research Methods. Nueva York: McGraw-Hill/Irwin, 2007.
Edwards, A. y R. Talbot. The Hard-Pressed Researcher. Nueva York: Longman, 1994.
Kendall, J. E. “Examining the Relationship Between Computer Cartoons and Factors in Information Systems Use, Success and
Failure; Visual Evidence of Met and Unmet Expectations”. The DATA BASE for Advances in Information Systems, Vol. 28,
Núm. 2, primavera de 1997, pp. 113-126.
Kendall, J. E. y K. E. Kendall. “Metaphors and Methodologies: Living Beyond the Systems Machine”. MIS Quarterly, Vol. 17,
Núm. 2, junio 1993, pp. 149-171.
Kendall, J. E. y K. E. Kendall. “Metaphors and Their Meaning for Information Systems Development”. European Journal of
Information Systems, 1994, pp. 37-47.
Kendall K. E. y J. E. Kendall. “Observing Organizational Environments: A Systematic Approach for Information Analysts”.
MIS Quarterly, Vol. 5, Núm. 1, 1981, pp. 43-55.
Kendall K. E. y J. E. Kendall. “STROBE: A Structured Approach to the Observation of the Decision-Making Environment”.
Information and Management, Vol. 7, Núm. 1, 1984, pp. 1-11.
Kendall, K. E. y J. E. Kendall. “Structured Observation of the Decision-Making Environment: A Validity and Reliability
Assessment”. Decision Sciences, Vol. 15, Núm. 1, 1984, pp. 107-118.
Markus, M. L. y A. S. Lee. “Special Issue on Intensive Research in Information Systems: Using Qualitative, Interpretive and Case
Methods to Study Information Technology—Second Installment”. MIS Quarterly, Vol. 24, Núm. 1, marzo de 2000, p.1.
Schultze, U. “A Confessional Account of an Ethnography About Knowledge Work”. MIS Quarterly, Vol. 24, Núm. 1, marzo de
2000, pp. 3-41.
Shultis, R. L. “‘Playscript’—A New Tool Accountants Need”. NAA Bulletin, Vol. 45, Núm. 12, agosto de 1964, pp- 3-10.
Webb, E. J., D. T. Campbell, R. D. Schwartz y L. Sechrest. Nonreactive Measures in the Social Sciences, 2da. edición. Stanford,
CT: CENGAGE Learning, 1981.www.xlibros.com

154 PARTE II ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
E P I S O D I O 5
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Ver es creer
“Chip, sé que las entrevistas tardaron mucho tiempo, pero valieron la pena”, dice Anna en tono defensivo mientras Chip entra
a su oficina con una mirada de preocupación en su rostro.
“Estoy seguro de ello”, dice Chip. “En realidad les dejaste una buena impresión. Las personas me han detenido en el pa-
sillo para decirme que están felices de que estemos trabajando en el nuevo sistema. No me preocupan las entrevistas en sí. Lo
que me preocupa es que no tuvimos tiempo para hablar sobre las observaciones antes de que hicieras las entrevistas”.
“Pierde cuidado, fui toda ojos”, se ríe Anna. “Utilicé una técnica llamada STROBE, Observación estructurada del entorno,
para ver de una manera sistemática los hábitats de nuestra persona encargada de tomar las decisiones. De seguro le interesarán
las notas que escribí para cada persona que entrevisté”, dice Anna, mientras entrega a Chip por escrito sus observaciones orga-
nizadas de cada una de las entrevistas.
EJERCICIOS
Para hacer estos ejercicios tiene que visitar el sitio Web para obtener las observaciones de las oficinas de los encargados de tomar
decisiones. Visite el sitio Web en www.pearsonhighered.com/kendall y busque la sección “CPU Observations of Decision Mak-
ers’ Offices” (Observaciones de la CPU sobre las oficinas de los encargados de tomar decisiones).
E-1. Con base en la observación que hizo Anna sobre la oficina y las vestimentas de Dot, use el método STROBE para anali-
zar a Dot como encargado de tomar decisiones. En dos párrafos, compare y contraste lo que aprendió en la entrevista de
Dot con lo que aprendió por medio del método STROBE.
E-2. Después de examinar las observaciones por escrito de Anna sobre la oficina de Mike Crowe, use el método STROBE
para analizar a Mike como encargado de tomar decisiones. ¿Qué diferencias (si las hay) puede ver entre la entrevista de
Mike y las observaciones de Anna sobre Mike? Responda en dos párrafos.
E-3. Use el método STROBE para analizar las observaciones por escrito de Anna sobre Cher Ware y Paige Prynter. Use dos
párrafos para comparar y contrastar el estilo de toma de decisiones de cada persona, según lo que revelen sus oficinas y
su vestimenta.
E-4. Use el método STROBE para analizar las observaciones por escrito de Anna sobre Hy Perteks. Ahora compare su análisis
con la entrevista de Hy. Use dos párrafos para discutir si STROBE confirma, niega, invierte o sirve como pista para buscar
más detalles en la narrativa de Hy (incluya preguntas adicionales que desee hacer a Hy para aclarar su interpretación).www.xlibros.com

155
C A P Í T U L O 6
Modelado ágil
y prototipos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender las raíces del modelado ágil en prototipos y los cuatro tipos principales
de éstos.
2. Usar prototipos para recopilar requerimientos humanos de información.
3. Comprender el concepto de RAD para usarlo en la recopilación de los requerimientos
humanos de información y el diseño de interfaces.
4. Comprender el modelado ágil y las prácticas básicas que lo diferencian de otras
metodologías de desarrollo.
5. Conocer la importancia de los valores fundamentales para el modelado ágil.
6. Comprender cómo mejorar la eficiencia, para trabajadores expertos, mediante el uso
de métodos estructurados o modelado ágil.
En este capítulo exploraremos el modelado ágil: una colección de innovadoras
metodologías para el desarrollo de sistemas centradas en el usuario. Aprenderá
sobre valores y principios, actividades, recursos, prácticas, procesos y herra-
mientas asociadas con las metodologías ágiles. Estas metodologías tienen sus
raíces en los prototipos, por lo que este capítulo se inicia con ellos para proveer
un mejor contexto de entendimiento; hacia la segunda mitad del capítulo
abordaremos la metodología ágil.
La creación de prototipos de sistemas de información es una técnica valiosa para recopilar
rápidamente información específica sobre los requerimientos de información de los usuarios.
En general, la creación de prototipos efectivos se debe llevar a cabo en las primeras etapas del
SDLC, durante la fase de determinación de requerimientos.
Incluimos los prototipos en este punto para recalcar su importancia como técnica de reco-
pilación de información. Al usar los prototipos de esta forma, el analista de sistemas busca las
reacciones iniciales de los usuarios y la gerencia con respecto al prototipo, las sugerencias de
los usuarios sobre cambiar o limpiar el sistema propuesto, las posibles innovaciones para éste
y los planes de revisión que definen las partes del sistema a implementar primero o las sucur-
sales de la empresa que seguirán.
Hay una variedad especial de prototipo en la que se utiliza una metodología orientada a
objetos, conocida como desarrollo rápido de aplicaciones (RAD). Los prototipos y RAD también
se pueden utilizar como método alternativo al SDLC.www.xlibros.com

156 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
PROTOTIPOS
Como analista de sistemas que va a presentar un prototipo del sistema de información, a usted le interesan
mucho las reacciones que tendrán los usuarios y la administración con respecto al prototipo. Debe anticipar
con precisión cómo reaccionarán al trabajar con el prototipo y qué tan bien se adaptarán a sus necesidades las
características del sistema previstas. Las reacciones se recopilan a través de la observación, entrevistas y hojas
de retroalimentación (posiblemente cuestionarios) diseñadas para obtener la opinión de cada persona sobre el
prototipo a medida que interactúa con él.
La información que se recopila en la fase de prototipos permite al analista establecer prioridades y redirigir
los planes sin sufrir repercusiones graves, con un mínimo de interrupción. Debido a esta característica, la crea-
ción de prototipos y la planeación van de la mano.
Tipos de prototipos
La palabra prototipo se utiliza en muchas formas; en vez de intentar una definición sintetizada de ellos, o de tra-
tar de forzar una metodología correcta para este tema controversial, vamos a ilustrar cómo se puede aplicar con
éxito cada una de las diversas concepciones de los prototipos en una situación específica, como se muestra en la
figura 6.1.
PROTOTIPO DE PARCHES El primer tipo alude a la construcción de un sistema funcional, parchado o construido
totalmente con parches. En ingeniería, a esta metodología se le conoce como “breadboarding”: crear un modelo
funcional de un circuito integrado (cuya forma final será microscópica) uniendo partes.
En términos de sistemas de información, se trata de un modelo funcional, con todas las características ne-
cesarias, pero que es ineficiente. En esta instancia del prototipo, los usuarios pueden interactuar con el sistema
y acostumbrarse a la interfaz y a los tipos de salidas disponibles. Sin embargo, los procesos de recuperación y
almacenamiento de información pueden ser ineficientes debido a que los programas se escribieron con rapidez,
con el objetivo de que fuera funcional en vez de eficiente.
Característica 3
Característica 1
Característica 5
Prototipo de características selectas
Prototipo no operacionalPrototipo de parches
Prototipo primero de una serie
Instalación 3
Instalación 2
Instalación 1
Entrada Proceso Salida
FIGURA 6.1
Cuatro tipos de prototipos (en el
sentido de las manecillas del
reloj, empezando en la esquina
superior izquierda).www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 157
PROTOTIPO NO OPERACIONAL La segunda concepción de prototipo es la del modelo a escala no funcional,
empleado para probar ciertos aspectos del diseño. Un ejemplo es el modelo a escala completa de un automóvil que
se utiliza en pruebas de túnel de viento. El tamaño y la forma del automóvil son precisos, pero el automóvil no es
funcional; se incluyen sólo las características esenciales para una prueba específica.
Sería pertinente un modelo de escala no funcional para un sistema de información cuyas aplicaciones requi-
rieran una codificación demasiado extensa como para incluirla en el prototipo, pero fuera útil hacerse una idea de
la entrada y la salida necesarias solamente. En este caso, no se crearía un prototipo del procesamiento, debido al
excesivo costo y tiempo requeridos. Los usuarios de todas formas podrían tomar decisiones en cuanto a la utili-
dad del sistema con base en el prototipo de la entrada y la salida.
PROTOTIPO PRIMERO DE UNA SERIE La tercera concepción de los prototipos es la creación de un modelo a escala
completa de un sistema, a lo que comúnmente se le conoce como piloto. Un ejemplo sería crear el prototipo del
primer aeroplano de una serie y después ver si puede volar antes de construir un segundo aeroplano. El prototipo
es completamente funcional; es una realización de lo que el diseñador espera sea una serie de aeroplanos con
características idénticas.
Este tipo de prototipo es útil cuando se planean muchas instalaciones del mismo sistema de información.
El modelo funcional a escala completa permite a los usuarios experimentar una interacción realista con el nuevo
sistema, al tiempo que minimiza el costo de solucionar los problemas que presenta. Por ejemplo, cuando una
cadena de tiendas de abarrotes al menudeo intenta usar el intercambio electrónico de datos (EDI) para verificar
los envíos de los proveedores en varios puntos de venta, se podría instalar un modelo a escala completa en una
tienda, antes de implementar el sistema en las demás, con el fin de que surjan los potenciales problemas de EDI
sólo ahí para resolverlos antes de que se extiendan en todos puntos de venta.
PROTOTIPO DE CARACTERÍSTICAS SELECTAS La cuarta concepción de los prototipos es la creación de un modelo
operacional que incluya sólo algunas características del sistema final. Una analogía sería un nuevo centro
comercial que abra antes de terminar de construir todas las tiendas.
Al crear prototipos de sistemas de información de esta forma, es posible incluir sólo algunas característi-
cas esenciales. Por ejemplo, el prototipo de un sistema mostraría a los usuarios un menú de pantalla con seis
características, agregar un registro, actualizar un registro, eliminar un registro, buscar una palabra clave en un
registro, listar un registro o escanear un registro, aunque sólo tres de las seis características estarían habilitadas
para usarse, de manera que el usuario pueda agregar un registro (característica 1), eliminar un registro (caracte-
rística 3) y listar un registro (característica 5). La retroalimentación de los usuarios puede ayudar a los analistas a
comprender lo que funciona y lo que no. También puede ayudar con las sugerencias sobre cuáles pueden ser las
siguientes características a agregar.
Mediante este tipo de creación de prototipos, el sistema se desarrolla en módulos, de manera que si los usua-
rios evaluaron positivamente las características presentadas, se pueden incorporar al sistema final sin tener que
trabajar mucho para interconectar los módulos. Los prototipos que se realizan de esta manera forman parte del
sistema actual. No son sólo un modelo, como en la creación de prototipos no operacionales que vimos antes.
A menos que se mencione lo contrario, todas las referencias que hagamos en este capítulo a los prototipos se re-
ferirán al prototipo de características selectas.
Uso de prototipos como alternativa para el SDLC
Algunos analistas argumentan que es necesario considerar a los prototipos como una alternativa al SDLC. En el
capítulo 1 vimos que el SDLC es una metodología lógica y sistemática para desarrollar sistemas de información.
Las quejas sobre tener que pasar por el proceso del SDLC se concentran en dos aspectos interrelacionados.
El primero es el largo tiempo requerido para pasar por el ciclo de vida de desarrollo. A medida que aumenta la
inversión de tiempo del analista, el costo del sistema entregado se eleva en forma proporcional.
La segunda es que los requerimientos del usuario cambian con el tiempo. Durante el extenso intervalo entre
el momento en que se analizan los requerimientos de los usuarios y el momento en el que se entrega el sistema
terminado, los requerimientos de los usuarios evolucionan. Así, debido al ciclo de desarrollo extendido, puede
suceder que el sistema resultante reciba críticas por abordar en forma inadecuada los requerimientos de informa-
ción actuales de los usuarios.
Además del problema de no estar al corriente con los requerimientos de información de los usuarios, se su-
giere que éstos no son conscientes de lo que desean o detestan sino hasta que conocen una propuesta concreta.
En el SDLC tradicional, a menudo es demasiado tarde para cambiar un sistema no deseado una vez que se en-
tregó al cliente.
Para lidiar con estos problemas, algunos analistas proponen utilizar los prototipos como alternativa al
SDLC, pues el analista recorta efectivamente el tiempo entre el proceso de averiguar los requerimientos huma-
nos de información y la entrega de un sistema funcional. Además, al usar prototipos en vez del SDLC tradicionalwww.xlibros.com

158 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
se podrían solucionar algunos de los problemas implicados con la identificación precisa de los requerimientos de
información de los usuarios.
Una desventaja de sustituir el SDLC con la creación de prototipos deriva de dar forma al sistema antes de
comprender perfectamente el problema o la oportunidad pertinente. Además, al usar los prototipos como alter-
nativa se podría producir un sistema que sea aceptado por ciertos grupos específicos de usuarios, pero que sea
inadecuado para las necesidades del sistema en general.
El método por el que abogamos en este libro es usar prototipos como parte del SDLC tradicional. Así po-
demos considerar a los prototipos como un método adicional especializado para averiguar los requerimientos de
información de los usuarios a medida que interactúan con los prototipos y proveen retroalimentación para el
analista.
DESARROLLO DE UN PROTOTIPO
Los prototipos son un medio excelente para obtener retroalimentación sobre el sistema propuesto y el grado en
que cumple con las necesidades de información de sus usuarios, como se muestra en la figura 6.2. El primer paso
de la creación de un prototipo es estimar los costos involucrados en la construcción de un módulo del sistema.
Si los costos del tiempo de los programadores y del analista, así como los costos del equipo están dentro del
presupuesto, se puede continuar con la construcción del prototipo. Ésta es una excelente manera de facilitar la
integración del sistema de información en la cultura y sistema, más extensos, de la organización.
Modifique su diseño
con base en las
reacciones a su
prototipo
FIGURA 6.2
Los analistas deben modificar los
diseños de sus pantallas originales
con base en las reacciones de los
usuarios al prototipo.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 159
Lineamientos para desarrollar un prototipo
Una vez tomada la decisión de crear un prototipo, hay que cumplir con cuatro lineamientos para integrar el pro-
totipo en la fase de determinación de requerimientos del SDLC:
1. Trabajar en módulos administrables.
2. Crear el prototipo con rapidez.
3. Modificar el prototipo.
4. Hacer énfasis en la interfaz de usuario.
Como puede ver, los lineamientos sugieren formas de proceder necesariamente interrelacionadas. En las siguien-
tes subsecciones explicaremos cada uno de ellos.
TRABAJAR EN MÓDULOS ADMINISTRABLES Al crear prototipos de algunas de las características de un sistema y
convertirlos en un modelo funcional, es imperativo que el analista trabaje en módulos administrables. Una de las
ventajas únicas de los prototipos es que no es necesario ni conveniente construir todo un sistema funcional para
usarlos.
Un módulo administrable permite a los usuarios interactuar con sus características clave y se puede construir
por separado. Las características del módulo que se consideran menos importantes se dejan intencionalmente
fuera del prototipo inicial. Como veremos más adelante en este capítulo, esto es muy similar a la metodología
ágil que hace énfasis en liberar pequeñas versiones.
CREAR EL PROTOTIPO CON RAPIDEZ La velocidad es esencial para la creación de un prototipo exitoso de un
sistema de información. Recuerde que una de las quejas sobre el SDLC tradicional es que el intervalo entre la
determinación de los requerimientos y la entrega de un sistema completo es demasiado largo como para poder
lidiar en forma efectiva con las necesidades en evolución de los usuarios.
Los analistas pueden usar prototipos para acortar este hueco mediante el uso de técnicas tradicionales de re-
copilación de información para señalar los requerimientos salientes de información, y después tomar decisiones
rápidas que produzcan un modelo funcional. En efecto, el usuario ve y utiliza el sistema desde las primeras eta-
pas del SDLC, en vez de tener que esperar un sistema terminado para obtener experiencia práctica.
Al ensamblar un prototipo operacional con la mayor rapidez y anticipación en el SDLC, el analista puede
obtener una valiosa comprensión acerca de cómo proceder con el resto del proyecto. Al mostrar a los usuarios en
las primeras etapas del proceso el desempeño real de las partes del sistema, la creación rápida de prototipos evita
comprometer recursos excesivos en un proyecto que tal vez llegue a fracasar. Más adelante, cuando examinemos
O P O R T U N I D A D D E C O N S U L T O R Í A 6 . 1
Los prototipos, ¿son los reyes?
“Como sabe, somos un grupo entusiasta. Todavía no nos con-
vertimos en dinastía, pero estamos trabajando en ello”, le dice Paul
LeGon. A sus 24 años, Paul (al que presentamos en la Oportunidad
de consultoría 2.3) es el “niño rey” de Pyramid, Inc., una pequeña
pero exitosa empresa editorial independiente especializada en li-
bros en rústica que están fuera de la corriente dominante en la in-
dustria editorial. Como analista de sistemas, usted ha sido contratado
por Pyramid, Inc. para desarrollar un sistema de información distri-
buida y un inventario de almacén computarizado.
“Estamos contratando muchos trabajadores”, continúa Paul,
como si quisiera convencerlo de la inmensidad de la empresa de Pyra-
mid. “Y creemos que Pyramid cuenta con un posicionamiento perfecto
en lo que respecta a nuestros mercados en el norte, sur, este y oeste”.
“Mi asistente Cecil Toom y yo hemos estado trabajando muy
duro, pensando en el nuevo sistema. Y hemos concluido que lo que
realmente necesitamos es un prototipo. De hecho, hemos descar-
tado mucho material. Nuestra fascinación con la idea en general
realmente ha tomado forma de pirámide”.
Mientras usted se prepara a formular una respuesta para Paul,
piensa en las semanas anteriores que trabajó con Pyramid, Inc.
Usted cree que los problemas de negocios que debe resolver su
sistema de información son bastante simples. También sabe que la
empresa tienen un presupuesto muy limitado y no puede darse el
lujo de gastar como reina. De hecho, el proyecto es bastante pe-
queño.
Ceil, basándose en los anteriores comentarios de Paul, le dice
a usted: “No es que estemos muy involucrados con los prototipos,
pero sentimos que representan el nuevo mundo. Y ahí es donde
queremos estar todos. Sabemos que necesitamos un prototipo. ¿Está
usted convencido?”.
Con base en el entusiasmo de Paul y Ceil por los prototipos y
lo que usted sabe sobre las necesidades de Pyramid, ¿apoyaría la
construcción de un prototipo? ¿Por qué sí o por qué no? Formule
su decisión y respuesta en una carta para Paul LeGon y Ceil Toom.
Presente una justificación para su decisión con base en los criterios
generales para justificar el uso de prototipos.www.xlibros.com

160 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U L T O R Í A 6 . 2
Despejando el camino para los vínculos con los clientes
la empresa World’s Trend (en el capítulo 7 encontrará una des-
cripción detallada de la corporación) está construyendo un sitio Web
para vender mercancía de liquidación (que por lo general se vende a
través de Web y por medio de su operación de ventas por catálogo).
Lincoln Cerf, el consultor Web recién contratado, llega a una ciudad
muy fría e invernal, luchando por avanzar a través de varias pulgadas
de nieve para reunirse con uno de los miembros del equipo de siste-
mas, Mary Mae, en las oficinas generales de World’s Trend.
Mary da la bienvenida a Lincoln y le dice: “¡Por lo menos el
clima no parece afectar nuestras ventas Web! No importa lo que
pase, siguen a un ritmo dinámico”. Lincoln emite un sonido para
aprobar el triste intento de chiste de Mary, sonríe y dice: “Descubrí
de tu lista de correo electrónico de la semana pasada que estás tra-
tando de determinar el tipo de información que hay que mostrar en
nuestro sitio Web de liquidación”.
Mary le responde: “Sí, estoy tratando de organizar todo de la
mejor manera posible. Nuestros clientes están muy ocupados. Sé
que las fotografías de toda nuestra mercancía pueden tardar mucho
tiempo en aparecer en la página si un cliente accede al sitio Web
mediante un módem lento desde su casa”. Mary continúa: “Linc, ni
siquiera me preocupa cómo diseñar nuestro sitio de liquidación en
este momento, sino cuánta información necesitamos incluir en una
página. Por ejemplo, cuando los artículos están en liquidación no
todos los colores y tamaños están disponibles. ¿Qué crees que es
mejor, incluir cierta información básica y dejar que el cliente haga
clic en un botón para solicitar más información, o mostrar la mayor
cantidad posible de detalles en una sola página? Si uso el método
de los vínculos, entonces puedo ajustar más artículos en la panta-
lla... pero podría ser demasiado ordenado. A los clientes les gusta
la apariencia y la sensación de una venta de mercancía agrupada en
montones”.
Para extender la idea de Mary, Linc dice: “Sí. Me pregunto
cómo quieren los clientes que se organice la información. ¿Los has
visto usar la Web? Es decir, ¿buscan zapatos cuando compran un
traje? Si es así, ¿deberían aparecer zapatos en la página de trajes o
estar vinculados de alguna forma?”.
Mary comenta: “Eso es lo que yo me pregunto también. Des-
pués me pregunto si deberíamos probar este método sólo en la ropa
de caballero primero, antes de implementarla en la ropa de damas.
¿Qué tal si la forma de comprar de los hombres y las mujeres en la
Web es distinta?”.
Como tercer miembro del grupo de desarrollo del sitio Web de
World’s Trend, responda con un breve informe por escrito para Lin-
coln y Mary acerca de si deben usar o no un prototipo para obtener
recomendaciones de clientes potenciales sobre el sitio Web propuesto.
¿Qué tipo de prototipo sería apropiado? Considere cada uno de los
tipos disponibles y explique por qué se podría aplicar (o no) cada uno
a este problema. Dedique un párrafo para cada explicación.
el concepto de RAD, podrá ver de nuevo la importancia de la creación rápida de sistemas. Además, el modelado
ágil también se basa en la práctica de tiempos de entrega cortos.
MODIFICAR EL PROTOTIPO Un tercer lineamiento para desarrollar el prototipo es que su construcción debe admitir
modificaciones. Para lograr esto hay que crearlo en módulos que no tengan un alto grado de interdependencia. Si
cumplimos con este lineamiento encontraremos menos resistencia cuando haya que modificar el prototipo.
Por lo general el prototipo se modifica varias veces, para lo cual pasa a través de varias iteraciones. Los
cambios en el prototipo deben acercar más el sistema a lo que los usuarios dicen que es importante. Cada modi-
ficación requiere de otra evaluación por parte de los usuarios.
El prototipo no es un sistema terminado. Entrar a la fase de creación del prototipo con la idea de que reque-
rirá modificaciones es una postura útil que demuestra a los usuarios qué tan necesaria es su retroalimentación
para mejorar el sistema.
HACER ÉNFASIS EN LA INTERFAZ DE USUARIO La interfaz del usuario con el prototipo (y con el sistema, en
última instancia) es muy importante. Como lo que realmente tratamos de lograr con el prototipo es hacer que
los usuarios articulen con más detalle sus requerimientos de información, deben ser capaces de interactuar con
facilidad con el prototipo del sistema. También deben ser capaces de ver cómo el prototipo les permitirá realizar
sus tareas. Para muchos usuarios, la interfaz es el sistema. No debe ser un obstáculo.
Aunque muchos aspectos del sistema quedarán sin desarrollarse en el prototipo, la interfaz de usuario debe
estar lo suficientemente desarrollada como para que los usuarios puedan acoplarse al sistema con rapidez y no
desanimarse. Los sistemas interactivos en línea que utilizan interfaces de GUI se adaptan de manera ideal a los
prototipos. En el capítulo 14 describiremos con detalle las consideraciones importantes en el diseño de HCI.
Desventajas de los prototipos
Al igual que sucede con cualquier otra técnica de recopilación de información, el uso de prototipos presenta
varias desventajas. La primera es que puede ser bastante difícil administrar la creación de un prototipo como un
proyecto dentro del esfuerzo más grande de sistemas. La segunda es que los usuarios y analistas pueden adoptarwww.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 161
un prototipo como sistema completo cuando todavía es inadecuado y aunque nunca haya tenido la intención de
servir como sistema terminado. Los analistas necesitan trabajar para asegurarse de que la comunicación con los
usuarios sea clara en cuanto a la agenda para interactuar con el prototipo y mejorarlo.
El analista debe comparar estas desventajas contra las ventajas conocidas al decidir si va a crear un proto-
tipo, cuándo se va a crear y qué tanto del sistema se va a incluir en el prototipo.
Ventajas de los prototipos
La utilización de prototipos no es necesaria o apropiada en todos los proyectos de sistemas, como hemos visto.
Sin embargo, las ventajas también se deben tener en consideración al decidir si debemos o no crearlos. Las tres
principales ventajas de los prototipos son el potencial de cambiar el sistema durante las primeras etapas de su
desarrollo, la oportunidad de detener el desarrollo en un sistema que no está funcionando y la posibilidad de de-
sarrollar un sistema que cumpla mejor con las necesidades y expectativas de los usuarios.
La creación de prototipos exitosos depende de la retroalimentación oportuna y frecuente de los usuarios, que
los analistas pueden usar para modificar el sistema y hacerlo más sensible a las necesidades actuales. Al igual
que con cualquier otro esfuerzo de sistemas, los cambios en las primeras etapas son menos costosos que los cam-
bios tardíos. En la última parte del capítulo verá cómo la metodología ágil para el desarrollo utiliza una forma
extrema de prototipos, en la que se requiere un cliente en el sitio de trabajo para que provea retroalimentación
durante todas las iteraciones.
Creación de prototipos mediante software COTS
Algunas veces, la forma más rápida de crear un prototipo es por medio de la instalación modular de software
COTS. Aunque podemos explicar con facilidad el concepto de COTS a través de los populares paquetes de un
O P O R T U N I D A D D E C O N S U L T O R Í A 6 . 3
Incubar un pez
“Sólo le pido un poco de paciencia. Creo que necesitamos agre-
gar unas cuantas características más antes de entregárselos. De no
ser así, todo este prototipo se hundirá, no flotará”, dice Sam Monroe,
miembro del equipo de análisis de sistemas que usted dirige. Los
cuatro miembros del equipo están sentados juntos en una reunión de
emergencia, y hablan sobre el prototipo que están desarrollando
de un sistema de información para ayudar a los gerentes a supervisar
y controlar la temperatura del agua, el número de peces liberados y
otros factores en un extenso criadero comercial de peces.
“Ya tienen muchos pendientes. Digo, el sistema empezó con
cuatro características y en estos momentos llevamos ya nueve. Me
siento como si nadáramos aguas arriba en esto. No necesitan todo
eso. Ni siquiera lo quieren”, argumenta Belle Uga, el segundo
miembro del equipo de análisis de sistemas. “No me gusta criticar,
pero pienso que debemos darles sólo lo básico. Tenemos suficiente
por hacer así como está”.
“Creo que Monroe está más cerca de lo correcto”, dice Wally
Idle, el tercer miembro del equipo para contribuir a la plática e inten-
tar que Belle muerda el anzuelo. “Tenemos que mostrarles lo mejor
de nosotros, incluso aunque signifique que nos atrasemos unas sema-
nas más de lo prometido para terminar nuestro prototipo”.
“Muy bien”, dice Belle con cautela, “pero quiero que ustedes
dos digan a los gerentes del criadero por qué no vamos a entregar el
prototipo. Yo no quiero hacerlo. Y no estoy seguro de que los suel-
ten del anzuelo tan fácilmente”.
Monroe responde: “Bien, creo que podemos hacerlo, pero tal
vez no deberíamos hacer tanto alarde de atrasarnos más de lo pen-
sado. No quiero hacer olas”.
Wally entra en la conversación: “Cierto. ¿Por qué señalar nues-
tros errores a todos? Además, cuando vean el prototipo se olvidarán
de las quejas que tenían. Les encantará”.
Belle descubre en su libreta un memo de su última reunión con
los gerentes del criadero y lo lee en voz alta: “Agenda para la reunión
de septiembre 22. ‘Prototipos: la importancia del desarrollo rápido,
reunir el equipo de analistas de usuarios, obtener retroalimentación
rápida para la modificación . . .”, la voz de Belle se apaga, omitiendo
los últimos puntos en la agenda. Después de sus comentarios, Monroe
y Wally se miran uno al otro con desconsuelo.
Monroe habla primero: “Creo que tratamos de preparar a to-
dos para que recibieran un prototipo rápidamente y que se involu-
craran desde el primer día”. Dándose cuenta de que usted ha estado
callado hasta ahora, Monroe continúa: “Pero aun así las aguas son
profundas. ¿Qué piensas que debemos hacer ahora?”, le pregunta
a usted.
Como cuarto miembro del equipo de análisis de sistemas, ¿qué
acciones piensa que se deben tomar? En un mensaje de correo electró-
nico de uno o dos párrafos para los miembros de su equipo, responda
a las siguientes preguntas: ¿Hay que agregar más características al
prototipo del sistema del criadero antes de entregarlo a los gerentes
del criadero para que experimenten con él? ¿Qué tan importante es el
desarrollo rápido del prototipo? ¿Cuáles concesiones pueden hacerse
al agregar más características al prototipo, en comparación con entre-
gar un prototipo más básico al cliente en el tiempo prometido? Com-
plete su mensaje con una recomendación.www.xlibros.com

162 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
O P O R T U N I D A D D E C O N S U L T O R Í A 6 . 4
Este prototipo está todo mojado
“Se puede modificar. Recuerda, no es un producto terminado”,
afirma Sandy Beach, analista de sistemas para RainFall, una gran
empresa fabricante de bañeras de fibra de vidrio y canceles para
baños. Beach trata ansiosamente de tranquilizar a Will Lather, un
programador de producción para RainFall, quien estudia minucio-
samente la primera copia impresa producida por el prototipo del
nuevo sistema de información.
“Bueno, está bien”, dice Lather en voz baja. “No me gustaría
molestarla con ningún detalle. Veamos... sí, aquí están”, dice al
localizar finalmente el informe mensual que sintetiza la materia
prima que se compró, la que se utilizó y la que está en inventario.
Lather continúa hojeando el pesado documento impreso. “Esto
está bien”. Al detenerse en un informe, exclama: “Voy a hacer que la
Señorita Fawcett copie esta parte para los de contabilidad”. Después
de hojear unas cuantas páginas más, dice: “Y el de aseguramiento de
calidad debería ver esta columna de cifras, aunque el resto no sea
de interés para él. Lo voy a circular y sacaré una copia para él. Tal vez
también deba pasar por teléfono una parte de esto al almacén”.
Mientras Sandy se prepara para salir, Lather junta las páginas
de los informes y comenta: “El nuevo sistema será una gran ayuda.
Voy a asegurarme de que todos lo conozcan. Cualquier cosa será
mejor que el ‘viejo monstruo’, de todos modos. Estoy feliz de que
tengamos algo nuevo”.
Sandy sale de la oficina de Will Lather con la sensación de
estar un poco perdida en el mar. Después de pensarlo, empieza a
darse cuenta por qué los departamentos de contabilidad, asegura-
miento de calidad y el almacén no reciben lo que Will piensa que
deberían recibir. Sandy telefonea a unas cuantas personas y con-
firma que lo que le dijo Lather es verdad. Necesitan los informes y
no los están recibiendo.
Más tarde en esa misma semana, Sandy se ve con Lather para
volver a canalizar la salida, así como cambiar algunas de las caracte-
rísticas del sistema. Estas modificaciones permitirán a Lather obtener
respuestas en pantalla en relación con los escenarios del tipo “qué pasa
si” que tratan sobre los cambios en los precios que cobran los provee-
dores, o los cambios en la proporción de calidad de la materia prima
disponible de los proveedores (o ambos), así como también le permi-
tirán ver lo que ocurriría si se atrasara un envío.
Lather está visiblemente molesto con las sugerencias de Sandy
en cuanto a modificar el prototipo y su salida. “Oh, por mí no lo
hagas. Está bien, de verdad. No me molesta acatar la responsabili-
dad de canalizar la información a las personas. Siempre los estoy
bombardeando con información de todas formas. De verdad, esto
está funcionando muy bien. No me gustaría que nos lo quitaras en
este momento. Dejémoslo así como está”.
Sandy está complacida de que Lather parezca estar tan satisfe-
cho con la salida del prototipo, pero le preocupa que Lather no esté
dispuesto a cambiarlo, ya que ha estado inculcando a los usuarios
que lo consideren como un producto en evolución y no como uno
terminado.
Escriba un informe breve para Sandy en el que incluya una lista
de cambios al prototipo en base a las reacciones de Lather. Describa
en un párrafo las formas en que Sandy puede calmar los miedos de
Lather sobre “quitarle” el prototipo. Describa en un párrafo algunas
de las acciones que se pueden tomar antes de probar un prototipo para
preparar a los usuarios en cuanto a su naturaleza evolutiva.
costo relativamente bajo tales como los productos Microsoft Office, hay otros paquetes de software COTS ela-
borados y costosos, pero muy útiles. Como ejemplo de implementación rápida de software COTS tenemos la
forma en que la Catholic University utiliza el paquete de software COTS ERP conocido como People Soft, que
se encarga de muchas de sus funciones basadas en Web.
La Catholic University, junto con un grupo de consultoría en educación superior y PeopleSoft, emprendieron
con éxito la implementación rápida de un módulo de reclutamiento y admisiones de su software COTS. Lanzaron
la implementación en abril de 1999 y para octubre de ese año habían implementado con éxito el reclutamiento
y las admisiones para los estudiantes universitarios. Para noviembre de ese mismo año, habían implementado
las mismas funciones para los estudiantes de postgrado. Otros módulos el software COTS de PeopleSoft que se
implementan en la Catholic University son un catálogo de cursos completo en línea, el registro en línea y la ca-
pacidad para que los estudiantes revisen sus calificaciones, transcripciones, cuentas y pagos de ayuda financiera
en línea, desde cualquier parte.
El papel que desempeñan los usuarios en los prototipos
El papel de los usuarios en los prototipos se puede resumir en dos palabras: participación honesta. Sin la parti-
cipación de los usuarios, los prototipos no tienen mucho sentido. Los comportamientos precisos necesarios para
interactuar con un prototipo pueden variar, pero está claro que el usuario es fundamental para el proceso de crea-
ción de prototipos. Teniendo en cuenta la importancia del usuario para el éxito del proceso, los miembros del
equipo de análisis de sistemas deben fomentar y agradecer la entrada y protegerse contra su propia resistencia
natural a cambiar el prototipo.
Hay tres formas principales en las que un usuario puede ayudar con los prototipos:
1. Experimentar con el prototipo.
2. Ofrecer reacciones abiertas al prototipo.
3. Sugerir lo que se puede agregar o quitar en el prototipo.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 163
Los usuarios deben tener la libertad de experimentar con el prototipo. A diferencia de una simple lista de ca-
racterísticas del sistema, el prototipo permite a los usuarios interactuar en forma práctica con el sistema. Montar
un prototipo en un sitio Web interactivo es una forma de facilitar esta interacción.
Otro aspecto del papel de los usuarios en los prototipos es que se requiere que expresen reacciones abiertas
al mismo. Los analistas tienen que estar presentes por lo menos parte del tiempo cuando ocurre la experimenta-
ción. De esta forma pueden observar las interacciones de los usuarios con el sistema y llegar a ver interacciones
que nunca planearon. En la figura 6.3 se muestra un formulario lleno para observar la experimentación del usua-
rio con el prototipo. Algunas de las variables a observar son las reacciones de los usuarios al prototipo, sus sugeren-
cias para cambiar o expandir el prototipo, sus innovaciones para usar el sistema en formas completamente nuevas
y cualquier plan de revisión para el prototipo que ayude a establecer las prioridades.
El tercer aspecto del papel que desempeñan los usuarios en los prototipos es su disposición para sugerir
elementos que se puedan agregar o quitar en base a las características que hayan experimentado. La función del
analista es obtener tales sugerencias al asegurar a los usuarios que la retroalimentación que ellos proveen se toma
en serio, al observar a los usuarios a medida que interactúan con el sistema y al llevar a cabo entrevistas cortas
y específicas con los usuarios en relación con sus experiencias con el prototipo. Aunque se pedirá a los usua-
rios que articulen sugerencias e innovaciones para el prototipo, al final es responsabilidad del analista ponderar
esta retroalimentación y traducirla en cambios funcionales en donde sea necesario. Para facilitar el proceso de
creación del prototipo, el analista debe comunicar con claridad los propósitos de la creación de prototipos a los
usuarios, junto con la idea de que los prototipos son valiosos sólo cuando los usuarios se involucran en forma
significativa.
DESARROLLO RÁPIDO DE APLICACIONES
El desarrollo rápido de aplicaciones (RAD) es una metodología orientada a objetos para el desarrollo de sistemas,
la cual incluye un método de desarrollo así como herramientas de software. Tiene sentido hablar sobre RAD y
los prototipos en el mismo capítulo ya que en concepto son muy parecidos. Ambos tienen como objetivo acortar
el tiempo que se necesita comúnmente en un SDLC tradicional entre el diseño y la implementación del sistema
de información. En última instancia, tanto RAD como la creación de prototipos tratan de cumplir en mejor grado
con los requerimientos de las empresas que cambian rápidamente. Una vez que se aprenden los conceptos sobre
Nombre del observador Fecha
Nombre del sistema o proyecto Empresa o ubicación
Nombre o número de programa Versión
Usuario 1 Usuario 2 Usuario 3 Usuario 4
Nombre de usuario
Periodo de observación
Reacciones de los
usuarios
Sugerencias de
los usuarios
Innovaciones
Planes de revisión
Michael Cerveris 1/06/2010
Centro de datos de computación en nube Aquarius Water Filters
Mant. Prev. 1
Andy H. Pam H.
1/06/2010 1/06/2010
Favorable en
general, se
emocionó sobre
el proyecto.
¡Excelente!
Agregar la fecha
en que se realizó
el mantenimiento.
Colocar un número
de formulario en la
parte superior para
referencia. Colocar
la palabra SEMANAL
en el título.
Modificar el
1/08/2010
Revisar con
Andy y Pam.
Formulario de evaluación del prototipo
FIGURA 6.3
Un paso importante en la creación
de prototipos es registrar en forma
adecuada las reacciones de los
usuarios, sus sugerencias,
innovaciones y planes de revisión.www.xlibros.com

164 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Identificar objetivos
y requerimientos
de información
Introducir el
nuevo sistema
Construir
el sistema
Planeación de
los requerimientos Implementación
Taller de diseño RAD
Trabajar con los
usuarios para
diseñar el sistema
FIGURA 6.4
El taller de diseño RAD es el
corazón del proceso de desarrollo
interactivo.
la creación de prototipos, es mucho más fácil entender los aspectos básicos de RAD, que se puede considerar
como una implementación específica de la creación de prototipos.
Algunos desarrolladores consideran a RAD como una metodología útil para los nuevos entornos de comer-
cio electrónico basado en Web, donde el denominado estatus del primer participante de un negocio podría ser
importante. En otras palabras, para implementar una aplicación en Web antes que sus competidores, tal vez sea
conveniente para las empresas que sus equipos de desarrollo experimenten con RAD.
Fases de RAD
Hay tres amplias fases para RAD en las que se involucra tanto a los usuarios como a los analistas en la evalua-
ción, el diseño y la implementación. En la figura 6.4 se describen estas tres fases. Observe que RAD involucra
a los usuarios en cada parte del esfuerzo de desarrollo, con una intensa participación en la parte comercial del
diseño.
FASE DE PLANEACIÓN DE LOS REQUERIMIENTOS En esta fase, los usuarios y analistas se reúnen para identificar
los objetivos de la aplicación o el sistema, y para identificar los requerimientos de información que surgen a
partir de estos objetivos. En esta fase se requiere una participación intensa de ambos grupos, y no consiste sólo
en la firma de una propuesta o documento. Además, es probable que se involucren usuarios de distintos niveles
de la organización (como vimos en el capítulo 2). En la fase de planeación de los requerimientos, cuando
todavía se está lidiando con los requerimientos de información, usted tal vez esté trabajando con el CIO (si es
una organización extensa) y con los planeadores estratégicos, en especial si elabora una aplicación de comercio
electrónico diseñada para ampliar las miras estratégicas de la organización. La orientación en esta fase es hacia la
solución de problemas de negocios. Aunque la tecnología de información y los sistemas puedan incluso impulsar
algunas de las soluciones propuestas, el enfoque siempre permanecerá en alcanzar los objetivos de negocios.
TALLER DE DISEÑO RAD Se trata de una fase de diseño y refinación que se puede caracterizar mejor como un
taller. Al imaginar un taller, usted sabe que la participación es intensa, no pasiva, y que por lo general implica
poner manos a la obra. Comúnmente, los participantes se sientan en mesas redondas o en configuración de U, con
los escritorios unidos, y cada participante puede ver a los demás y hay espacio para trabajar en una computadora
portátil. Si es lo bastante afortunado como para tener disponible una sala de sistemas de soporte de decisiones en
grupo (GDSS) en la empresa o por medio de una universidad local, úsela para realizar cuando menos parte de su
taller de diseño RAD.
Durante el taller de diseño RAD, los usuarios responden a los prototipos funcionales reales y los analistas
refinan los módulos diseñados (mediante el uso de algunas de las herramientas de software que mencionaremos
más adelante) con base en las respuestas de los usuarios. El formato del taller es muy estimulante, y si están pre-
sentes usuarios y analistas experimentados, no hay duda de que este esfuerzo creativo puede impulsar el desarro-
llo con un ritmo acelerado.
FASE DE IMPLEMENTACIÓN En la figura anterior puede ver que, durante el taller, los analistas trabajan
intensivamente con los usuarios para diseñar los aspectos de negocio o los aspectos no técnicos del sistema. Tan
pronto como se llega a un consenso sobre estos aspectos, y se crean y refinan los sistemas, se prueban los nuevos
sistemas o las nuevas partes de los mismos y después se introducen a la organización. Como RAD se puede usar
para las nuevas aplicaciones de comercio electrónico para las cuales no hay un sistema anterior, a menudo no hay
necesidad ni posibilidad de ejecutar los sistemas anterior y nuevo en paralelo antes de la implementación.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 165
Para este momento, el taller de diseño RAD debe haber generado emoción, la sensación de que los usuarios
son propietarios de la nueva aplicación y aceptación de la misma. Por lo general, el cambio que se produce de
esta forma es menos traumático que cuando un sistema se entrega y el usuario tuvo poca o nula participación.
Comparación entre RAD y el SDLC
En la figura 6.5 puede comparar las fases del SDLC con las que se describieron con detalle para RAD al prin-
cipio de esta sección. Tenga en cuenta que el propósito primordial de RAD es acortar el SDLC y de esta forma
responder más rápido a los requerimientos dinámicos de información de las organizaciones. El SDLC requiere
un enfoque más metódico y sistemático que asegure la integridad y precisión; además tiene como intención la
creación de sistemas que integren bien a los procedimientos de negocios estándar y a la cultura.
Introducir
el sistema
Introducir el
sistema
Trabajar con los
usuarios para
diseñar el sistema
Construir
el sistema
Taller de trabajo de diseño RAD
Fases de planeación de requerimientos y análisisFases de diseño, desarrollo y documentación
Identificar objetivos
y requerimientos
de información Identificar
oportunidades
y objetivos
Determinar
requerimientos de
información;
desarrollar
diagramas E-R
Analizar las
necesidades del
sistema; desarrollar
DFD y repositorios
de datos
Diseñar el
sistema
recomendado
Desarrollar y
documentar el
sistema
Probar el
sistema
Retroalimentación
de los usuarios
Usar la entrada de
los usuarios
El método RAD
permite un desarrollo
rápido.
El método SDLC
permite realizar de
manera sistemática
y cuidadosa el análisis,
diseño y documentación
de los sistemas.
FIGURA 6.5
Comparación entre los métodos
del taller de diseño RAD y SDLC.www.xlibros.com

166 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
La fase del taller de diseño RAD es una desviación de las fases de diseño estándar del SDLC, debido a que
se utilizan herramientas de software RAD para generar pantallas y exhibir el flujo en general de la ejecución de
la aplicación. De esta forma, cuando los usuarios aprueban el diseño, lo hacen con base en una representación
visual del modelo y no sólo un diseño conceptual representado en papel, como es comúnmente el caso.
La fase de implementación de RAD es en muchas formas menos extenuante que otros métodos, debido a
que los usuarios ayudaron a diseñar los aspectos de negocios del sistema y están bien conscientes de los cambios que
ocurrirán. Hay pocas sorpresas y el cambio es algo que se espera con agrado. Al usar el SDLC, a menudo hay
un extenso periodo durante el desarrollo y el diseño en que los analistas están separados de los usuarios. Durante
este periodo los requerimientos pueden cambiar y tal vez los usuarios no estén conscientes de que el producto
final será distinto al que se esperaba muchos meses atrás.
CUÁNDO USAR RAD Como analista, es conveniente que aprenda sobre todas las metodologías y herramientas
que le sea posible para facilitar el proceso de hacer su trabajo de la manera más apropiada. El trabajo en algunas
aplicaciones y sistemas requerirá el uso de ciertas metodologías. Considere usar RAD cuando:
1. Su equipo incluya programadores y analistas que tengan experiencia con este método y se dé cualquiera de
las siguientes condiciones.
2. La empresa tenga motivos para presionar de manera que se pueda agilizar cierta parte del desarrollo de una
aplicación.
3. Cuando trabaje con una aplicación original de comercio electrónico y su equipo de desarrollo crea que la
empresa puede obtener una ventaja considerable frente a sus competidores por ser innovadora si esta
aplicación está entre las primeras en aparecer en Web.
4. Cuando los usuarios sean sofisticados y se involucren mucho con los objetivos organizacionales de la
empresa.
DESVENTAJAS DE RAD Al igual que con otros tipos de creación de prototipos, las dificultades con RAD surgen
debido a que los analistas de sistemas tratan de apurar demasiado el proyecto. Suponga que se contratan dos
carpinteros para construir dos cobertizos de almacenamiento para dos vecinos. El primer carpintero sigue la
filosofía del SDLC, mientras que el segundo sigue la filosofía RAD.
El primer carpintero es sistemático, hace un inventario de todas las herramientas, podadoras de césped y pie-
zas de muebles de jardín para determinar el tamaño correcto del cobertizo, diseña un plano del cobertizo y escribe
especificaciones para cada pieza de madera y accesorios de ferretería. El carpintero construye el cobertizo sin
desperdiciar muchos recursos y cuenta con documentación precisa sobre cómo construyó el cobertizo, en caso de
que alguien desee construir otro igual, repararlo o pintarlo usando el mismo color.
El segundo carpintero empieza de inmediato con el proyecto mediante una estimación del tamaño del cober-
tizo, consigue un camión lleno de madera y accesorios de ferretería, construye una estructura y habla sobre ella
con el dueño de la propiedad a medida que se hacen modificaciones cuando no hay ciertos materiales disponi-
bles, y hace un viaje para devolver la madera que no se utilizó. El cobertizo se construye con mayor rapidez, pero
si no se dibuja un plano, la documentación nunca existirá.
MODELADO ÁGIL
Los métodos ágiles son una colección de metodologías innovadoras para el desarrollo de sistemas, las cuales se
centran en los usuarios. En esta sección aprenderá sobre valores y principios, actividades, recursos, prácticas,
procesos y herramientas asociadas con las metodologías ágiles. A estos métodos se les acreditan muchos proyec-
tos exitosos de desarrollo de sistemas y en muchos casos también se les acredita el haber rescatado empresas de
un sistema fallido diseñado mediante el uso de una metodología estructurada.
Valores y principios del modelado ágil
La metodología ágil se basa no sólo en resultados, sino también en valores, principios y prácticas. Los valores y
principios establecidos son esenciales para la programación ágil; estos valores y principios crean el contexto para
la colaboración entre programadores y clientes. Para poder ser analistas ágiles, hay que adherirse a los siguientes
valores y principios desarrollados por Beck (2000) en su trabajo sobre el modelado ágil, al cual denominó “pro-
gramación extrema” o “XP”.
CUATRO VALORES DEL MODELADO ÁGIL Hay cuatro valores que crean un entorno en el que tanto los desarrolla-
dores como las empresas pueden obtener el mismo servicio. Como a menudo hay tensión entre lo que hacen los
desarrolladores a corto plazo y lo comercialmente deseable a largo plazo, es importante propugnar en forma deliberada
los valores que formarán la base para actuar en conjunto en un proyecto de software. Los cuatro valores son
comunicación, simpleza, retroalimentación y valor, como se muestra en la figura 6.6.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 167
Empecemos con la comunicación. En todo esfuerzo humano existe la posibilidad de una mala comunica-
ción. Los proyectos de sistemas que requieren de una constante actualización y diseño técnico son especialmente
propensos a dichos errores. Si aunamos a ello tiempos de entrega ajustados, jerga especializada y el estereotipo
de que los programadores prefieren hablar con las máquinas en vez de las personas, terminamos con el potencial de
toparnos con serios problemas de comunicación. Los proyectos pueden sufrir retrasos; se puede resolver el pro-
blema incorrecto; los programadores reciben castigo incluso hasta por llevar los problemas a los gerentes; la
gente sale o se une a mitad del proyecto sin las actualizaciones apropiadas, y la letanía continúa.
Las prácticas ágiles comunes como la programación en pareja (dos programadores que colaboran entre sí;
describiremos esta práctica más adelante en el capítulo), la estimación de tareas y la prueba de unidades depen-
den mucho de la buena comunicación. Los problemas se corrigen con rapidez, los orificios se tapan y el pensa-
miento débil se fortalece rápidamente por medio de la interacción con otros miembros del equipo.
El segundo valor de la metodología ágil es la simpleza. Cuando trabajamos en un proyecto de desarrollo de
software, nuestra primera tendencia es abrumarnos con la complejidad y tamaño de la tarea. Sin embargo, no po-
demos correr sino hasta aprender a caminar, ni podemos caminar hasta no aprender a erguirnos. La simpleza para
el desarrollo de software significa que debemos empezar con la cosa más simple que podamos hacer.
El valor ágil de la simpleza nos pide hacer la cosa más sencilla hoy, a sabiendas de que tal vez mañana ten-
gamos que cambiarla un poco. Para ello debemos estar enfocados claramente en los objetivos del proyecto, lo
cual es en realidad un valor básico.
La retroalimentación es el tercer valor básico importante cuando usamos una metodología de programa-
ción extrema. Al considerar la retroalimentación en este contexto, es bueno tener en cuenta que está implicada
con el concepto del tiempo. Una buena retroalimentación concreta que sea útil para el programador, el analista
y el cliente puede ocurrir en cuestión de segundos, minutos, días, semanas o meses, dependiendo de lo que se
requiera, de quién se esté comunicando y de lo que se pretenda hacer con la retroalimentación. Un compañero
programador podría pasarle un caso de prueba que quebrante el código que usted acaba de escribir, pero esa
retroalimentación es invaluable en términos de poder cambiar lo que no funciona antes de que se acepte y se in-
cruste en el sistema.
La retroalimentación ocurre cuando los clientes crean pruebas funcionales para todas las historias que hayan
implementado posteriormente los programadores (más adelante en el capítulo podrá ver más sobre las historias
de los usuarios). La retroalimentación crítica sobre la programación de fechas y tiempos proviene de los clientes
que comparan el objetivo del plan con el progreso realizado hasta ese momento. La retroalimentación ayuda a
los programadores a realizar ajustes y permite a la empresa empezar a experimentar con mucha antelación lo que
será el nuevo sistema una vez que sea completamente funcional.
La valentía es el cuarto valor en la programación ágil. El valor de la valentía tiene que ver con un nivel de
confianza y confort que debe existir en el equipo de desarrollo. Significa no tener miedo de desperdiciar una
tarde o un día de programación y empezar de nuevo si no todo está bien. Significa poder estar en contacto con
los instintos de uno mismo (y los resultados de prueba) en relación con lo que funciona y lo que no.
Valentía también significa responder a la retroalimentación concreta, actuando con base en las corazonadas
de sus compañeros de equipo cuando ellos piensan que tienen una forma más simple y mejor de obtener su ob-
jetivo. La valentía es un valor de alto riesgo y un gran nivel de recompensa, el cual fomenta la experimentación
que puede llevar al equipo a obtener su objetivo con más rapidez de una manera innovadora. Valentía significa que
usted y los miembros de su equipo confían entre sí y en sus clientes lo suficiente como para actuar en formas
que mejoren de manera continua lo que se está llevando a cabo en el proyecto, incluso si esto implica descartar
código, reformular las soluciones o simplificar más las metodologías. La valentía también implica que usted,
como analista de sistemas, aplique con entusiasmo las prácticas de la metodología ágil.
Los analistas pueden reflejar de una mejor forma los cuatro valores por medio de una postura de humildad.
A través de la historia, el software de computadora se desarrolló por expertos que a menudo pensaban que sabían
S
i
m
p
l
e
z
a
R
e
t
r
o
a
l
i
m
e
n
t
a
c
i
ó
n
C
o
m
u
n
i
c
a
c
i
ó
n
V a l o
r
Valores
ágiles
FIGURA 6.6
Los valores son imprescindibles
para la metodología ágil.www.xlibros.com

168 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
cómo operar una empresa de una mejor forma que los clientes locales, que eran los verdaderos expertos. Con fre-
cuencia, a los expertos de computadora se les denominaba “gurús”. Algunos de los gurús exhibían grandes egos
e insistían en su infalibilidad, incluso cuando sus clientes no lo creían así. Muchos gurús carecían de la virtud de
la humildad.
Es imprescindible mantener una postura humilde durante el desarrollo de sistemas. Usted debe hacerse a la
idea de que si el usuario está expresando una dificultad, entonces hay que lidiar con ella. No podemos ignorarla.
Los modeladores ágiles son analistas de sistemas que hacen sugerencias, expresan opiniones pero nunca insisten
en que tienen la razón el 100 por ciento del tiempo. Los modeladores ágiles poseen la suficiente confianza en sí
mismos como para permitir que sus clientes cuestionen, critiquen y, algunas veces, se quejen sobre el sistema
que están desarrollando. Los analistas aprenden de sus clientes, quienes han estado en el negocio durante un
buen tiempo.
LOS PRINCIPIOS BÁSICOS DEL MODELADO ÁGIL En un mundo perfecto, los clientes y su equipo de desarrollo
de software se verían directamente a los ojos y no sería necesaria ninguna otra forma de comunicación. Todos
estaríamos de acuerdo en todo momento. Sabemos que el mundo ideal no existe, Pero ¿cómo podemos acercar
nuestros proyectos de desarrollo de software a ese ideal? Parte del por qué no ocurrirá esto se debe a que
hasta ahora estamos tratando de operar con base en un sistema impreciso de valores compartidos. Son un buen
principio, pero en realidad no se ponen en la práctica hasta el punto en que nos sea posible medir nuestro éxito
significativamente. Por lo tanto, trabajamos para derivar los principios básicos que pueden ayudarnos a verificar
que lo que realmente estamos haciendo en nuestro proyecto de software sea estar a la altura de los valores que
compartimos.
Los principios ágiles son reflejos y especificaciones de los valores ágiles. Sirven como lineamientos que los de-
sarrolladores pueden seguir al desarrollar sistemas. También sirve para diferenciar a las metodologías ágiles de las
metodologías más tradicionales basadas en planes como SDL, así como las metodologías orientadas a objetos.
Beck y sus colaboradores fueron los primeros en describir los principios ágiles, que han evolucionado desde
entonces. Estos principios se pueden expresar en una serie de dichos tales como:
1. Satisfacer al cliente por medio de la entrega de software funcional.
2. Adoptar el cambio, incluso si se introduce en las últimas etapas del desarrollo.
3. Seguir entregando software funcional en incrementos y con frecuencia.
4. Fomentar a los clientes y analistas a que trabajen juntos a diario.
5. Confiar en los individuos motivados para que realicen su trabajo.
6. Promover la conversación cara a cara.
7. Concentrarse en hacer que el software funcione.
8. Fomentar el desarrollo continuo, regular y sostenible.
9. Adoptar la agilidad con especial atención en un diseño lúcido.
10. Apoyar a los equipos autoorganizados.
11. Proveer retroalimentación rápida.
12. Fomentar la calidad.
13. Revisar y ajustar el comportamiento de vez en cuando.
14. Adoptar la simpleza.
Con frecuencia escuchará a los desarrolladores ágiles a medida que comunican su opinión por medio de
dichos como los antes mencionados, o incluso frases más simples tales como “modelar con un propósito”, “el
software es su objetivo primario” y “viaje ligero”, una forma de decir que es suficiente con poca documentación.
Escuche estos dichos con cuidado. En el capítulo 16 hablaremos más sobre ellos (algunos los llaman proverbios)
bajo una herramienta de análisis y documentación conocida como FOLKLORE. Las frases pegajosas son fáciles
de entender, memorizar y repetir. Son muy efectivas.
Actividades, recursos y prácticas del modelado ágil
El modelado ágil involucra una serie de actividades a completar en cierto momento durante el proceso de desa-
rrollo ágil. En esta sección hablaremos sobre esas actividades, los recursos y las prácticas que son únicas para la
metodología ágil.
CUATRO ACTIVIDADES BÁSICAS DEL DESARROLLO ÁGIL Hay cuatro actividades básicas de desarrollo que utilizan
los métodos ágiles: codificar, probar, escuchar y diseñar. El analista necesita identificar el grado de esfuerzo
requerido por cada actividad para compararlo con los recursos necesarios para completar el proyecto.
La codificación es la actividad indispensable. Un autor establece que lo más valioso que recibimos del có-
digo es el “aprendizaje”. El proceso es fundamentalmente el siguiente: elija una idea, codifíquela, pruébela ywww.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 169
compruebe si la idea era lógica. El código también se puede usar para comunicar ideas que, de otra manera,
permanecerían borrosas o deformes; cuando examine su código, tal vez incluso le surjan nuevas ideas. El código
fuente es la base de un sistema viviente. Es esencial para el desarrollo.
La prueba es la segunda actividad básica del desarrollo. La metodología ágil considera que las pruebas
automatizadas son imprescindibles. La metodología ágil aboga por la escritura de pruebas para verificar codi-
ficación, funcionalidad, rendimiento y cumplimiento. El modelado ágil se basa en las pruebas automatizadas;
existen extensas bibliotecas de pruebas para la mayoría de los lenguajes de programación. Estas pruebas necesitan
actualizarse según se requiera durante el progreso del proyecto.
Hay razones tanto de largo como de corto plazo para las pruebas. Las pruebas a corto plazo nos ofrecen
una confianza extrema sobre lo que estamos construyendo. Si las pruebas se cumplen a la perfección, podemos
continuar con una confianza renovada. A largo plazo, las pruebas mantienen vivo a un sistema y permiten rea-
lizar cambios durante un periodo más extenso del que hubiera sido posible si no se hubieran escrito o realizado
pruebas.
Escuchar es la tercera actividad básica del desarrollo. En el capítulo 4 aprendimos sobre la importancia de
escuchar durante las entrevistas. En la metodología ágil, el proceso de escuchar se lleva al extremo. Los desa-
rrolladores utilizan la escucha activa para oír a su socio de programación. En el modelado ágil hay menos de-
pendencia de la comunicación formal por escrito, por lo que escuchar se convierte en una habilidad de suma
importancia.
El desarrollador también utiliza la escucha activa con el cliente. Los desarrolladores asumen que no saben
nada sobre las empresas a las que están ayudando, por lo que deben escuchar con cuidado a los empresarios para
obtener las respuestas a sus preguntas. El desarrollador necesita llegar a comprender lo que es la escucha efec-
tiva. Si usted no escucha, no sabrá qué codificar o probar.
La cuarta actividad básica en el desarrollo es el diseño, que es una forma de crear una estructura para orga-
nizar toda la lógica en el sistema. El diseño es evolutivo, y por ende los sistemas que se diseñan mediante el mé-
todo ágil se conceptualizan como sistemas que siempre están en evolución y siempre están siendo diseñados.
A menudo es simple lograr un buen diseño. Éste debe permitir también cierto grado de flexibilidad. Diseñar
bien permite extender el sistema realizando cambios en un solo lugar. El diseño efectivo posiciona la lógica cerca
de los datos sobre los cuales va a operar. Por encima de todo, el diseño debe ser útil para todos aquellos que lo
necesiten a medida que avanza el esfuerzo de diseño, incluyendo clientes y programadores.
CUATRO VARIABLES DE CONTROL DE RECURSOS DEL MODELADO ÁGIL Es admirable completar todas las
actividades en el proyecto a tiempo y dentro de todas las restricciones pero, como probablemente habrá
averiguado para estos momentos, para lograr esto es imprescindible administrar el proyecto correctamente.
Y esto implica no sólo reunir todas las tareas y recursos; también significa que el analista sacrifique algunas
ventajas por otras. Algunas veces el costo puede estar predeterminado, mientras que otras veces el tiempo puede
llegar a ser el factor más importante. A continuación hablaremos sobre estas variables de control de recursos
(tiempo, costo, calidad y alcance).
TIEMPO Hay que asignar tiempo suficiente para completar el sistema, y entender que lo necesita para varias
actividades distintas: escuchar a los clientes, diseñar, codificar y probar.
Uno de nuestros amigos es propietario de un restaurante de comida china. Hace poco se quedó sin uno de los
miembros de su confiable equipo, quien regresó a Hong Kong para casarse. El dueño ocupó el lugar en la cocina
para que la comida se sirviera a tiempo, pero dejó de estar al frente dando la bienvenida a sus clientes de la forma
usual. Sacrificó la actividad de escucha para cumplir con otra actividad, pero en este caso se percató de que esto
dañaba su negocio. Los clientes querían la atención.
Lo mismo ocurre en el desarrollo de sistemas. Puede crear software de calidad, pero fracasar a la hora de
escuchar. Puede elaborar un diseño perfecto, pero no asignar el tiempo suficiente como para probarlo. El tiempo
es difícil de manejar. Si se agota el tiempo, ¿qué debe hacer?
El método ágil desafía la noción de que más tiempo nos dará los resultados que queremos. Tal vez el cliente
prefiera que usted termine a tiempo en vez de extender el tiempo de entrega para agregar otra característica.
A menudo descubrimos que los clientes son felices si parte de la funcionalidad está trabajando a tiempo. Nuestra
experiencia muestra que con frecuencia un cliente está un 80 por ciento satisfecho con el primer 20 por ciento
de la funcionalidad. Esto significa que cuando completemos el otro 80 por ciento del proyecto, el cliente tal vez
sólo esté un poco más feliz de lo que estaba cuando habíamos completado sólo el 20 por ciento. La moraleja aquí
es que debe tener cuidado de no extender su tiempo de entrega. El método ágil insiste en terminar a tiempo.
COSTO El costo es la segunda variable que podríamos ajustar. Suponga que las actividades de codificación,
diseño, prueba y escucha están sobrecargando el proyecto y los recursos que invertimos en el tiempo, alcance y lawww.xlibros.com

170 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
calidad no son suficientes, incluso aunque dediquemos una cantidad normal al costo para equilibrar el proyecto.
En esencia, tal vez tengamos que contribuir más recursos que requieran dinero para balancear el proyecto.
La forma más sencilla de aumentar el gasto (y por ende los costos) es contratar más personal. Esto puede
parecer la solución perfecta. Si contratamos más programadores terminaremos más rápido. ¿Cierto? No nece-
sariamente. Imagine contratar dos personas para reparar un techo y aumentar el número a cuatro. Pronto los
trabajadores estarán chocando entre sí. Lo que es más, necesitan preguntarse unos a otros qué es lo que queda
por hacer. Y si aparece una tormenta eléctrica, nadie estará trabajando. Pasar de dos a cuatro no significa que se
requerirá la mitad del tiempo. Considere el aumento requerido en la comunicación y otros costos intangibles a
la hora de decidir si va a contratar más personal. Recuerde que cuando se unen nuevos miembros a un equipo,
no conocen el proyecto ni al equipo. Van a hacer más lentos a los miembros originales debido a que éstos deben
dedicar parte del tiempo para ayudar a que los nuevos miembros se pongan al corriente.
El tiempo extra no ayuda mucho tampoco. Aumenta el costo, pero no siempre aumenta la productividad.
Los programadores cansados son menos efectivos que los programadores que se mantienen alertas, tardan mucho
tiempo en completar una tarea y también cometen errores que cuestan incluso más tiempo corregir.
¿Hay algo más en lo que podamos gastar nuestro dinero? Tal vez. A medida que lea los capítulos siguientes,
conocerá varias herramientas que ofrecen soporte para los analistas y programadores. A menudo estas herramien-
tas son una inversión sabia. Por ejemplo, los analistas utilizan paquetes gráficos tales como Microsoft Visio para
comunicar ideas sobre el proyecto a los demás, y las herramientas CASE tales como Visible Analyst también
ayudan a agilizar los proyectos.
Incluso el nuevo hardware podría ser un gasto que valga la pena. Las computadoras portátiles y los teléfo-
nos inteligentes mejoran la productividad cuando está uno alejado de la oficina. Las pantallas de mayor tamaño,
los teclados y ratones con capacidad para Bluetooth y tarjetas gráficas más potentes también pueden mejorar la
productividad.
CALIDAD La tercera variable de control de recursos es la calidad. Si los sistemas ideales son perfectos, ¿por qué
hay que poner tanto esfuerzo en dar mantenimiento a los sistemas? ¿Acaso estamos practicando ya el desarrollo
ágil al sacrificar la calidad en el desarrollo de software? En el capítulo 16 veremos la importancia de la calidad y
los métodos (como TQM y Seis Sigma) que ayudan a asegurar un alto grado de calidad en el software.
Sin embargo, la filosofía ágil permite al analista ajustar este recurso y tal vez hacer un menor esfuerzo por
mantener la calidad que si se utilizara otro método. La calidad se puede ajustar en forma externa e interna: la in-
terna involucra la prueba de software con base en factores tales como la funcionalidad (¿Qué es lo que se supone
que debe hacer un programa?) y el cumplimiento (¿Cumple el software con ciertos estándares de conformidad y
se puede mantener?). Por lo general no es redituable experimentar con la calidad interna.
Eso nos deja con la calidad externa, o la forma en que el cliente percibe el sistema. Al cliente le interesa el
rendimiento. Algunas de las preguntas que un cliente puede hacer son: ¿Actúa el programa en forma confiable
(o aún existen errores en el software)? ¿Es efectiva la salida?, ¿llega a tiempo? ¿Se ejecuta el software sin es-
fuerzo? ¿Es la interfaz de usuario fácil de comprender y usar?
En el extremo de la filosofía del desarrollo ágil es permisible sacrificar ciertas cuestiones de calidad exter-
nas. Para que el sistema se pueda liberar a tiempo, tal vez el cliente tenga que lidiar con algunos errores en el
software. Si queremos cumplir nuestro tiempo de entrega, tal vez la interfaz de usuario no sea perfecta. Podre-
mos mejorarla en una próxima versión.
Los fabricantes de software comercial de venta en canales convencionales sacrifican la calidad: podemos
debatir si es o no es la metodología correcta. Por lo tanto, no le sorprenda cuando las aplicaciones de software de
su PC (sin mencionar su sistema operativo y explorador Web) se actualicen con frecuencia, si los desarrolladores
utilizan la programación extrema como una de sus prácticas ágiles.
ALCANCE Por último tenemos el alcance. En la metodología ágil, para determinar el alcance hay que escuchar a
los clientes y hacer que escriban sus historias, que se examinan después para determinar cuánto se puede hacer
en un tiempo dado para satisfacerlos. Las historias deben ser breves y fáciles de comprender. Más adelante en
el capítulo describiremos estas historias con más detalle; mientras tanto, he aquí un breve ejemplo que muestra
cuatro historias de un sistema en línea de viajes en avión. Cada una de las historias se muestra en negrita:
Mostrar vuelos alternativos
Preparar una lista de los cinco vuelos más económicos.
Ofrecer alternativas más económicas
Sugerir a los clientes que viajen otro día, que tomen un especial de fin de semana, promociones
especiales o que utilicen otros aeropuertos alternos.
Comprar un boleto
Permitir al cliente comprar boletos directamente con una tarjeta de crédito (verificar validez).www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 171
Permitir al cliente elegir su asiento
Llevar al cliente a una representación visual del aeroplano y pedirle que seleccione un asiento.
Lo ideal sería que el analista pudiera determinar cuánto tiempo y dinero se requieren para completar cada
una de estas historias, y que pudiera establecer el nivel de calidad para cada una de ellas también. Es obvio que
este sistema no debe sacrificar la calidad, ya que de otra forma las compras con tarjeta de crédito serían inválidas
o los clientes podrían presentarse en el aeropuerto sin reservaciones.
Una vez más, las prácticas ágiles permiten medidas extremas, por lo que para mantener la calidad, adminis-
trar el costo y completar el proyecto a tiempo, tal vez sea conveniente para el analista ágil ajustar el alcance del
proyecto. Para lograr esto hay que hacer que el cliente esté de acuerdo en retrasar una o más de las historias hasta
la siguiente versión del software. Por ejemplo, tal vez la funcionalidad de permitir que los clientes seleccionen
sus propios asientos se pueda postergar para la próxima versión.
En resumen, el analista ágil puede controlar cualquiera de las cuatro variables de recursos de tiempo, costo,
calidad y alcance. La agilidad exige medidas extremas y considera muy importante el hecho de completar un
proyecto a tiempo. Para ello hay que hacer sacrificios y el analista ágil descubrirá que es difícil decidir en cuanto
a las concesiones que debe hacer.
CUATRO PRÁCTICAS ÁGILES BÁSICAS Hay cuatro prácticas básicas que marcan una diferencia considerable entre
la metodología ágil y las demás metodologías: entregas pequeñas, semana de trabajo de 40 horas, alojar al cliente
en el sitio, y programar en pareja.
1. En las entregas pequeñas, el equipo de desarrollo comprime el tiempo entre entregas de su producto. En
vez de entregar una versión completa con todas las características en un año, mediante el uso de la práctica
de entregas pequeñas reducen el tiempo de entrega al resolver las características más importantes primero y
entregar ese sistema o producto para mejorarlo más adelante.
2. En la semana de trabajo de 40 horas, los equipos de desarrollo ágil patrocinan una práctica básica cultural en
la que el equipo trabaja intensamente durante una semana laboral de 40 horas. Como corolario de esta
práctica, la cultura refuerza la idea de que trabajar tiempo extra por más de una semana consecutiva es
dañino para la salud del proyecto y de los desarrolladores. Esta práctica básica intenta motivar a los
miembros del equipo para que trabajen en forma intensa y después se tomen tiempo de descanso, para que
cuando regresen se encuentren relajados y menos estresados. Esto ayuda a los miembros del equipo a
detectar problemas con más facilidad, al tiempo que evita costosos errores y omisiones debido a un
rendimiento inefectivo o al agotamiento.
3. Alojar al cliente en el sitio; es decir, tener “en casa”, durante el proceso de desarrollo, a un usuario experto
en el aspecto de negocios relacionado con el trabajo de desarrollo de sistemas. Esta persona es muy
importante para el proceso: escribe las historias de los usuarios, se comunica con los miembros del equipo,
ayuda a asignar prioridades y equilibrar las necesidades a largo plazo de la empresa, y toma decisiones en
cuanto a la característica que se deba resolver primero.
4. La programación en pareja es una importante práctica básica. Aquí usted trabaja con otro programador que
usted mismo haya elegido. Ambos realizan la codificación y las pruebas. A menudo la persona con más
experiencia emprenderá el proceso de codificación primero, pero a medida que la menos experimentada se
empiece a involucrar, el que tenga la visión clara sobre el objetivo será quien se encargue de la codificación.
Cuando usted le pide a otra persona que trabajen juntos, el protocolo de la programación en pareja indica
que debe estar obligado a aceptar. Al trabajar con otro programador usted puede comprender con más
claridad su forma de pensar. Las parejas cambian con frecuencia, en especial durante la etapa de exploración
del proceso de desarrollo. La programación en pareja ahorra tiempo, reduce el pensamiento torpe, suscita la
creatividad y es una forma divertida de programar.
En la figura 6.7 se muestra la forma en que las prácticas ágiles apoyan y se interrelacionan con las activida-
des, recursos y valores del desarrollo ágil
El proceso de desarrollo ágil
El modelado es una palabra clave en los métodos ágiles. El modelado ágil aprovecha la oportunidad de crear
modelos que pueden ser lógicos, como los dibujos de los sistemas, o maquetas de tamaño natural como los
prototipos que describimos anteriormente en este capítulo. Un proceso ordinario de modelado ágil podría ser el
siguiente:
1. Escuchar las historias de los usuarios por medio del cliente.
2. Dibujar un modelo del flujo de trabajo lógico para apreciar las decisiones de negocios representadas en la
historia de un usuario.
3. Crear historias de usuarios con base en el modelo lógico.www.xlibros.com

172 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
4. Desarrollar algunos prototipos de visualización. Para ello hay que mostrar a los clientes el tipo de interfaz
que tendrán.
5. Usar la retroalimentación de los prototipos y los diagramas del flujo de trabajo lógico para desarrollar el
sistema hasta crear un modelo físico de datos.
Ágil es la otra palabra clave en el modelado ágil. Ágil implica capacidad de maniobrar. Los sistemas ac-
tuales, en especial los que están basados en Web, imponen demandas gemelas: entregar el software tan pronto
como sea posible y seguir mejorándolo para agregar nuevas características. El analista de sistemas necesita tener
la capacidad y los métodos para crear aplicaciones dinámicas, sensibles al contexto, escalables y evolutivas. El
modelado ágil como tal es un método que adopta el cambio.
ESCRIBIR LAS HISTORIAS DE LOS USUARIOS Incluso cuando el título de esta sección es “Escribir las historias
de los usuarios”, el énfasis en la creación de las historias de los usuarios está en la interacción oral entre los
desarrolladores y los usuarios, y no en la comunicación escrita. En las historias de los usuarios, el desarrollador
busca principalmente obtener de los usuarios requerimientos de negocios pertinentes. Por lo general, los usuarios
se involucran en conversaciones a diario con los desarrolladores en relación con el significado de las historias de
usuario que escribieron. Estas conversaciones frecuentes son interacciones intencionales que tienen como meta
evitar malos entendidos o malas interpretaciones en cuanto a los requerimientos de los usuarios. Por lo tanto, las
historias de usuarios sirven como recordatorios para los desarrolladores de que deben sostener conversaciones
dedicadas a esos requerimientos.
A continuación se muestra como ejemplo una serie de historias escritas para una aplicación de comercio
electrónico de un comerciante de libros, CD y demás medios. Las historias proporcionan una imagen bastante
completa de lo que se necesita en cada una de las etapas del proceso de compras, además de ser muy cortas y
fáciles de comprender. El objetivo aquí es sacar a la luz todas las necesidades y preocupaciones relacionadas con
la tienda en línea. Aunque no se puede obtener suficiente información de una historia como para empezar a pro-
gramar, un desarrollador ágil podría empezar a ver la imagen general con la suficiente claridad para empezar a
estimar lo que se requiere para completar el proyecto. Las historias son:
S
e
m
a
n
a
d
e
t
r
a
b
a
j
o
d
e
40
h
o
r
a
s
C
l
i
e
n
t
e
e
n
e
l
s
i
t
i
o
E
n
t
r
e
g
a
s
p
e
q
u
e
ñ
a
s
P
r
o
g
r a m
a
c
i
ó
n
e
n
p
a
r
e
j
a
C
o
s
t
o
C
a
l
i
d
a
d
T
i
e
m
p
o
A l c a
n
c
e
P
r
u
e
b
a
E
s
c
u
c
h
a
C
o
d
i
f
i
c
a
c
i
ó
n
D
i
s
e
ñ
o
Actividades ágiles
Prácticas ágiles básicas
Recursos ágiles
S
i
m
p
l
e
z
a
R
e
t
r
o
a
l
i
m
e
n
t
a
c
i
ó
n
C
o
m
u
n
i
c
a
c
i
ó
n
V
a
l
e
n
t
í
a
Valores ágiles
FIGURA 6.7
Las prácticas básicas están
interrelacionadas con los recursos,
actividades y valores del modelado
ágil.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 173
Dar la bienvenida al cliente
Si el cliente ya ha visitado antes este sitio y con la misma computadora, dar la bienvenida al cliente de
vuelta a la tienda en línea.
Mostrar los especiales en la página inicial
Mostrar los libros recientes u otros productos que se hayan introducido en forma reciente. Si el cliente se
identificó, personalizar las recomendaciones en base a ese cliente específico.
A T R A C T I V O D E L A M A C
Así como las metodologías ágiles representan una alternativa para el SDLC, OmniFocus es una alternativa a Microsoft
Project u otros métodos para realizar gráficos de Gantt o diagramas PERT.
Un observador casual podría pensar que los métodos ágiles carecen de estructura debido a que los sistemas se
construyen sin especificar detalles ni documentación. Un estudiante de los métodos ágiles descubre que en realidad hay
un buen grado de estructura en la metodología ágil. Los principios incluyen apegarse a la semana de trabajo de 40 horas
y la coordinación por medio de la programación en parejas. Un analista que adopte las técnicas ágiles necesita una forma
de establecer los objetivos, mantenerse dentro del presupuesto, establecer prioridades para las características y averi-
guar cómo hacer las cosas.
OmniFocus se basa en un sistema alternativo de administración de tareas desarrollado por David Allen, al cual se le
conoce como Getting Things Done. Este principio primordial trata sobre liberar la mente de recordar cosas, de manera que
podamos concentrarnos en llevarlas a cabo. Un analista que utilice este sistema tiene que efectuar cinco acciones: recolec-
tar, procesar, organizar, revisar y hacer.
Los analistas de sistemas que utilicen OmniFocus tienen que recolectar elementos de su navegador Web, su libreta
de direcciones o su calendario, o de la mayoría de las aplicaciones en una Mac. El analista puede categorizar estos
elementos o asignarlos a un proyecto más grande. OmniFocus incluye un modo de planeación para que el analista pueda
ver qué tarea forma parte de un proyecto más grande, así como un modo de contexto para organizar las tareas de manera
que el analista conozca todas las tareas que haya que realizar vía telefónica, navegando en Web o mediante el correo
electrónico. OmniFocus también está disponible como aplicación para iPhone.
FIGURA 6.MAC
OmniFocus de The Omni Group.www.xlibros.com

174 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Buscar el producto deseado
Incluir un motor de búsqueda efectivo que localice el producto específico, así como productos similares.
Mostrar títulos similares y disponibilidad
Mostrar los resultados de la búsqueda en una nueva página Web.
Permitir que el cliente pida más detalles
Ofrecer al cliente más detalles sobre los productos, como páginas de muestra de un libro, más fotografías
de un producto o la reproducción parcial de una pista de un CD.
Mostrar reseñas del producto
Compartir los comentarios de otros clientes sobre el producto.
Colocar un producto en un carrito de compras
Facilitar al cliente el proceso de hacer clic en un botón para colocar el producto en un carrito de
compras con los productos que pretende comprar.
Mantener el historial de compras en un archivo
Mantener los detalles sobre el cliente y sus compras en una cookie en la computadora del cliente.
También mantener la información sobre su tarjeta de crédito para agilizar el proceso de pasar a pagar
Sugerir libros similares
Incluir fotografías de otros libros que tengan temas similares o que hayan sido escritos por los mismos
autores.
Pasar a pagar
Confirmar la identidad del cliente.
Revisar las compras
Permitir que el cliente revise las compras.
Continuar con el proceso de compra
Ofrecer al cliente la oportunidad de realizar más compras al mismo tiempo.
Aplicar métodos de acceso directo para agilizar el proceso de pago
Si se conoce la identidad del cliente y la dirección de entrega coincide, agilizar la transacción al aceptar
la tarjeta de crédito en el archivo y el resto de las preferencias del cliente, como el método de envío.
Agregar nombres y direcciones de envío
Si la compra es un regalo, permitir que el cliente introduzca el nombre y la dirección de la persona que
lo va a recibir.
Ofrecer opciones de envío
Permitir al cliente elegir un método de envío con base en el costo.
Completar la transacción
Terminar la transacción. Pedir la confirmación de la tarjeta de crédito si la dirección de envío es distinta
de la dirección del cliente que se tiene en archivo.
Es fácil ver que historias no faltan. El analista ágil necesita elegir unas cuantas, completar la programación y
entregar un producto. Una vez hecho esto, se seleccionan más historias y se entrega una nueva versión hasta que
se incluyan todas en el sistema (o cuando el analista y el cliente estén de acuerdo en que una historia no vale la
pena o no es urgente, por lo que no necesita incluirla).
En la figura 6,8 se muestra un ejemplo de cómo podría aparecer una historia de usuario para un desarrolla-
dor ágil. En las tarjetas (o en formato electrónico) el analista podría identificar primero la necesidad u oportu-
nidad, para después continuar con una breve descripción de la historia. El analista puede empezar a pensar en
términos generales sobre las actividades a completar, así como los recursos que se requerirán para terminar el
proyecto. En este ejemplo del comerciante en línea, el analista indica que la actividad de diseño requerirá de un
esfuerzo superior al promedio, y que se requieren recursos de tiempo y calidad por arriba del promedio. Tenga
en cuenta que el analista no trata de ser más preciso de lo actualmente posible en la estimación, pero de todas
formas es un ejercicio útil.
SCRUM Scrum o melé es otra de las metodologías ágiles. La palabra scrum proviene de una posición inicial en
el rugby, donde los equipos forman un grupo y pelean por la posesión de la pelota. Fundamentalmente, scrum se
refiere al trabajo en equipo, algo similar a lo que se necesita para jugar rugby.
Así como los equipos de rugby llegan a un juego con una estrategia general, también los equipos de desa-
rrollo empiezan el proyecto con un plan de alto nivel que se puede modificar al instante, a medida que avanza el
“juego”. Los miembros del equipo de desarrollo de sistemas deben tener en cuenta que el éxito del proyecto es
lo más importante y que su éxito individual es secundario. El líder del proyecto tiene sólo un poco de influenciawww.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 175
Necesidad u oportunidad Aplicar métodos de acceso directo para agilizar el proceso de pago.
Historia
Muy por debajo
CodificaciónActividades
Prueba
Escucha
Diseño
TiempoRecursos
Costo
Calidad
Alcance
Debajo del promedio Promedio Arriba del promedio Muy por arriba
Si se conoce la identidad del cliente y la dirección de entrega coincide, agilizar la transacción al
aceptar la tarjeta de crédito en el archivo y el resto de las preferencias del cliente, como el método
de envío.
FIGURA 6.8
Las historias de los usuarios se pueden registrar en tarjetas. La historia de usuario debe ser lo bastante
breve como para que un analista pueda determinar las características de sistemas que se necesitan
sobre los detalles. Por eso el juego táctico se deja a los miembros del equipo, como si estuvieran en el campo de
juego. El equipo de sistemas trabaja dentro de un estricto periodo (30 días para el desarrollo), de igual forma que
un equipo de rugby juega dentro de un tiempo estrictamente limitado.
Podemos describir los componentes de la metodología de scrum así:
1. Acumulación (backlog) de productos, en donde se deriva una lista a partir de las especificaciones de los
productos.
2. Acumulación de corrida (sprint), una lista que cambia en forma dinámica sobre las tareas que se van a
completar en la siguiente corrida.
3. Corrida, un periodo de 30 días en donde el equipo de desarrollo transforma la acumulación en software que
se puede demostrar.
4. Scrum diaria, una reunión breve en donde la comunicación es la regla número uno. Los miembros del equipo
necesitan explicar lo que hicieron desde la última reunión, si se toparon con obstáculos y lo que planean
hacer antes de la siguiente scrum diaria.
5. Demo, software funcional que se puede demostrar al cliente.
Sin duda, scrum es una metodología de alta intensidad, y es sólo una de las filosofías que el modelado ágil
adopta.
Lecciones aprendidas a partir del modelado ágil
La metodología ágil, que con frecuencia se plantea como una manera alternativa de desarrollar sistemas, busca
resolver las quejas comunes surgidas al usar la metodología SDLC tradicional (debido a que requiere de mucho
tiempo, se enfoca en los datos en vez de los humanos y es demasiado costosa) al ser rápida, iterativa, flexible y
participativa al momento de responder a los requerimientos humanos de información, las condiciones y los entor-
nos de negocios, que están en constante evolución.
Existen crónicas de varios proyectos de desarrollo ágil en libros, artículos y sitios Web. Muchos de ellos
fueron exitosos y algunos fracasaron, pero podemos aprender bastante al estudiarlos, al igual que los valores, los
principios y las prácticas básicas de la metodología ágil. A continuación le mostraremos las seis lecciones impor-
tantes que aprendimos al examinar el modelado ágil. La figura 6.9 ilustra estas seis lecciones.
La primera lección es que las entregas pequeñas permiten a los sistemas evolucionar. Las actualizaciones
de los productos se realizan con frecuencia y los cambios se incorporan con rapidez. De esta forma, el sistema
puede crecer y expandirse en formas útiles para el cliente. Por medio de las entregas pequeñas, el equipo de de-
sarrollo comprime el tiempo entre las entregas de su producto, con lo cual puede mejorar el producto después, a
medida que la situación dinámica lo exija.
La segunda lección es que la programación en pareja mejora la calidad en general. Aunque este tipo de progra-
mación es controversial, en definitiva promueve otras actividades positivas necesarias en el desarrollo de sistemas:www.xlibros.com

176 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Los recursos y las
actividades equilibradas
apoyan los objetivos
del proyecto
Los clientes en el
sitio son benéficos para
ambas partes
Lecciones que se
obtienen al adoptar
los métodos ágiles
Los valores ágiles
son imprescindibles
para el éxito
La programación en
parejas mejora la
calidad en general
Las entregas
pequeñas permiten a
los sistemas
evolucionar
La semana de trabajo
de 40 horas mejora
la efectividad
FIGURA 6.9
Hay seis lecciones vitales que se
pueden aprender de la metodología
ágil para los sistemas.
una buena comunicación, lograr identificarse con el cliente, enfocarse en los aspectos más valiosos del proyecto
primero, evaluar todo el código a medida que se desarrolla e integrar el nuevo código una vez que pase las pruebas
con éxito.
La tercera lección es que los clientes en el sitio son benéficos tanto para la empresa como para el equipo de
desarrollo ágil. Los clientes actúan como una referencia preparada y una comprobación de la realidad; además
siempre se mantiene el enfoque del diseño del sistema a través de su presencia: los clientes se hacen más pareci-
dos a los desarrolladores y éstos se identifican mejor con los clientes.
La cuarta lección es que la semana de trabajo de 40 horas mejora la efectividad. Incluso los desarrolladores
más resistentes son susceptibles a errores y agotamiento si trabajan demasiado por un periodo muy extenso. Sin
embargo, cuando el equipo de desarrollo está unido, cada momento cuenta. Es mucho más conveniente trabajar a
un ritmo sostenible durante la vida del proyecto, la vida del sistema y ¡la vida del trabajador! Todos conocemos
la parábola de la liebre y la tortuga.
La quinta lección que obtenemos de la metodología ágil es que los recursos y las actividades equilibradas
apoyan los objetivos del proyecto. Administrar un proyecto no significa sólo reunir todos los recursos y tareas.
También significa que el analista tiene que lidiar con varias concesiones. Algunas veces el costo puede estar
predeterminado, mientras que otras veces el tiempo puede llegar a ser el factor más importante. Las variables de
control de recursos de tiempo, costo, calidad y alcance necesitan estar balanceadas en forma apropiada con las
actividades de codificación, diseño, prueba y escucha.
La última lección que obtenemos de las metodologías de modelado ágil es que los valores ágiles son impres-
cindibles para el éxito. Es esencial para el éxito en general del proyecto que los analistas adopten sin reservas
los valores de comunicación, simpleza, retroalimentación y valentía en todo el trabajo que realicen. Este tipo de
compromiso personal y con el equipo permite al analista triunfar en donde fracasarán otros que posean compe-
tencias técnicas similares pero carezcan de los valores. La verdadera dedicación a estos valores es fundamental
para un desarrollo exitoso.
COMPARACIÓN ENTRE EL MODELADO ÁGIL Y LOS MÉTODOS
ESTRUCTURADOS
Como hemos visto, los métodos ágiles se desarrollan con rapidez, ciertamente funcionan y los usuarios son
clientes que están involucrados de manera directa. Aunque es cierto que los proyectos desarrollados por medio
de métodos ágiles a menudo requieren de un ajuste para que funcionen de manera apropiada, los desarrolladores
ágiles admiten que esto es parte del proceso. La metodología ágil implica muchas entregas pequeñas, y durante
el proceso se van agregando más características.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 177
Mejorar la eficiencia en el trabajo del conocimiento: comparación entre SDLC y el método ágil
Los investigadores (Davis y Naumann, 1999) desarrollaron una lista de siete estrategias que pueden mejorar la
eficiencia del trabajo del conocimiento: reducir el tiempo y los errores de la interfaz; reducir el tiempo de apren-
dizaje del proceso y las pérdidas duales de procesamiento; reducir el tiempo y esfuerzo requeridos para estruc-
turar tareas y aplicar formato a las salidas; reducir la expansión improductiva del trabajo; reducir la búsqueda de
datos y de conocimiento, junto con el tiempo de almacenamiento y los costos; reducir la comunicación, el tiempo
de coordinación y los costos; y reducir las pérdidas debido a la sobrecarga humana de información. Ellos creen
que esto es importante, ya que con base en el estudio que hicieron de un grupo de programadores, afirman que
los mejores programadores son de cinco a diez veces más productivos que los peores. Además señalan que esta
proporción es sólo de dos a uno para los trabajadores que desempeñan labores de oficina o físicas. Su sugerencia
es que el software puede ayudar a mejorar muchas situaciones.
Utilizamos la metodología estándar y tradicional de desarrollo de sistemas de los métodos estructurados para
comparar y contrastar la forma en que las metodologías estructuradas y las metodologías ágiles implementarían
las siete estrategias propuestas para mejorar la eficiencia de los trabajadores del conocimiento.
Aunque el hecho de adoptar más software puede en definitiva mejorar también el rendimiento, es razonable
sugerir que si cambiamos una metodología también podría mejorar el rendimiento. En consecuencia examinare-
mos minuciosamente cada aspecto de la productividad del trabajo del conocimiento, tanto de las metodologías
estructuradas como de las ágiles. La figura 6.10 muestra una lista de las siete estrategias originales para mejorar
la productividad y después explica qué métodos se utilizan para mejorar la eficiencia del desarrollo de sistemas,
tanto para las metodologías ágiles como para las estructuradas.
En las siguientes secciones compararemos y contrastaremos las metodologías estructuradas con la meto-
dología ágil. Una observación primordial sobre la metodología ágil es que es una metodología orientada a los
humanos que permite a las personas crear soluciones matizadas que son imposibles de crear por medio de espe-
cificaciones formales de proceso.
REDUCCIÓN DE LOS TIEMPOS Y ERRORES DE LA INTERFAZ Los analistas de sistemas y los programadores
necesitan analizar, diseñar y desarrollar sistemas mediante el uso de herramientas de trabajo que varían desde
Microsoft office hasta herramientas CASE, que son costosas y sofisticadas. También necesitan realizar la
documentación a medida que desarrollan sistemas. Es importante que los analistas y los programadores sean
capaces de comprender la interfaz que utilizan. Necesitan saber cómo clasificar, codificar, almacenar y escribir
sobre los datos que recopilan. Los desarrolladores de sistemas también necesitan acceder con rapidez a un
programa, escribir la información requerida y recuperarla cuando la necesiten de nuevo.
Estrategias para mejorar la Eficiencia
en el trabajo del conocimiento
Implementación mediante
Metodologías estructuradas
Implementación mediante
Metodologías ágiles
Reducir el tiempo y los errores de
la interfaz
Adoptar estándares organizacionales para
codificar, asignar nombres, etc.; usar formularios
Adoptar la programación
en pareja
Reducir el tiempo de aprendizaje del
proceso y las pérdidas duales de
procesamiento
Administrar las entregas de las actualizaciones,
para que el usuario no tenga que aprender y
usar el software al mismo tiempo
Creación de prototipos
ad hoc y desarrollo
rápido
Reducir el tiempo y esfuerzo requeridos
para estructurar las tareas y aplicar
formato a las salidas
Usar herramientas y diagramas CASE; usar
código escrito por otros programadores
Fomentar las entregas
pequeñas
Reducir la expansión improductiva
del trabajo
Administración del proyecto; establecer
tiempos de entrega
Limitar el alcance en
cada entrega
Reducir el tiempo y costos del
almacenamiento, la investigación de
datos y del conocimiento
Usar técnicas estructuradas de recopilación
de datos, como las entrevistas, la
observación y el muestreo
Permitir un cliente en
el sitio
Reducir el tiempo y costos de
la comunicación y la coordinación
Separar los proyectos en tareas más
pequeñas; establecer barreras
Reducir las pérdidas debido a la
sobrecarga humana de información
Aplicar técnicas de filtrado para proteger
a los analistas y programadores
Usar cajas de tiempo
(timeboxing)
Apegarse a una semana
de trabajo de 40 horas
FIGURA 6.10
Cómo se pueden implementar las estrategias de Davis y Naumann para mejorar la
eficiencia mediante el uso de dos metodologías de desarrollo distintas.www.xlibros.com

178 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Las metodologías estructuradas fomentan la adopción de estándares para todo. Las reglas establecidas in-
cluyen elementos como. “Todos deben usar Microsoft Word en vez de Word Perfect”. Puede haber instrucciones
más detalladas para asegurar datos limpios tales como: “Use siempre M para Masculino y F para Femenino”, con
lo cual se asegura que los analistas no seleccionen sus propios códigos sin estandarizar, como 0 para Masculino
y 1 para Femenino. Así, estas reglas se convierten en parte del repositorio de datos. Los formularios también
son útiles, pues requieren que todo el personal documente sus procedimientos de manera que otro programador
pueda hacerse cargo si es necesario.
En una metodología ágil, los formularios y procedimientos funcionan bien también, pero se añade otro ele-
mento. La práctica adicional de la programación en pareja asegura que un programador verificará el trabajo del
otro, con lo cual se reduce el número de errores. Programar en pareja significa que se comparte la autoría del diseño
o del mismo software como una sociedad. Ambos socios (en donde por lo general uno de ellos es programador, a
menudo experimentado) dirán que eligieron un socio de programación que deseara tener un producto de calidad
libre de errores. Como trabajan dos personas en el mismo diseño y código, el tiempo de la interfaz no representa
un problema; es una parte integral del proceso. Los autores han observado que los programadores son bastante
emotivos cuando se menciona el tema de la programación en pareja.
REDUCIR EL TIEMPO DE APRENDIZAJE DEL PROCESO Y LAS PÉRDIDAS DUALES DE PROCESAMIENTO Los analistas
y los programadores aprenden técnicas específicas y lenguajes de software requeridos para completar un
proyecto actual. A menudo se producen ineficiencias cuando algunos analistas y programadores ya conocen los
productos que se van a utilizar, mientras que otros aún necesitan aprender a usarlos. Por lo general pedimos que
los desarrolladores aprendan a usar estos productos al mismo tiempo que los utilizan para construir el sistema.
Esta capacitación en el trabajo ralentiza de manera considerable el proyecto de desarrollo de sistemas en su
totalidad.
Un proyecto tradicional y estructurado requiere más aprendizaje. Si se utilizaran herramientas CASE, un
analista tendría que aprender a usar las herramientas CASE propietarias que se utilizan en la organización. Lo
mismo se aplica al uso de un lenguaje de computadora específico. La documentación también es una cuestión
importante.
Mediante el uso de una filosofía ágil, la habilidad de lanzar proyectos sin usar herramientas CASE y docu-
mentación detallada permite a los analistas y programadores invertir la mayor parte de su tiempo en el desarrollo
del sistema, en vez aprender a usar herramientas específicas.
REDUCCIÓN DEL TIEMPO Y ESFUERZO REQUERIDOS PARA ESTRUCTURAR TAREAS Y APLICAR FORMATO A LAS
SALIDAS Cada vez que un proyecto se inicia, los desarrolladores necesitan determinar los límites. En otras
palabras, necesitan saber cuál será el producto entregable y cómo organizarán el proyecto de manera que puedan
completar todas las tareas necesarias.
Una metodología tradicional incluiría el uso de herramientas CASE, dibujar diagramas (como los diagramas
E-R y los de flujo de datos), usar software de administración de proyectos (como Microsoft Project), descripcio-
nes de trabajo muy detalladas, usar y reutilizar formularios y plantillas, y reutilizar el código escrito por otros
programadores.
El desarrollo de sistemas mediante una metodología ágil hace frente a la necesidad de estructurar tareas me-
diante la programación de entregas pequeñas. La filosofía ágil sugiere que los desarrolladores de sistemas deben
crear una serie de tiempos de entrega para muchas versiones del sistema. Las primeras entregas poseerán menos
características pero, en cada nueva entrega se agregarán características adicionales.
REDUCCIÓN DE LA EXPANSIÓN IMPRODUCTIVA DEL TRABAJO La ley de Parkinson establece que “el trabajo se
expande para poder llenar el tiempo disponible para completarlo”. Si no hay tiempos de entrega específicos, es
posible que el trabajo del conocimiento continúe su expansión.
Con las metodologías estructuradas tradicionales, al principio los tiempos de entrega parecen estar muy
alejados hacia el futuro. Los analistas pueden utilizar técnicas de administración de proyectos para tratar de pro-
gramar las actividades, pero hay una predisposición integrada en cuanto a extender las primeras tareas más de lo
necesario y después tratar de acortarlas en una etapa posterior del desarrollo. Los analistas y los programadores
se preocupan menos por los tiempos de entrega distantes que por los que ya están próximos.
Una vez más, la metodología ágil hace énfasis en las entregas pequeñas. Se pueden entregar versiones en
el tiempo prometido, tal vez con menos de las características que se prometieron en un principio. Al considerar
todos los tiempos de entrega inminentes se destaca una expectativa realista en cuanto a la terminación (cuando
menos parcial) del proyecto.
REDUCCIÓN DEL TIEMPO Y COSTOS DE ALMACENAMIENTO Y DE LA INVESTIGACIÓN DE LOS DATOS Y DEL
CONOCIMIENTO Los desarrolladores de sistemas necesitan recopilar información sobre la organización, los
objetivos, las prioridades y los detalles acerca de los sistemas de información actuales antes de proceder con el
desarrollo de un nuevo sistema. Los métodos de recopilación de datos incluyen las entrevistas, la administración de
cuestionarios, la observación y la investigación mediante el análisis de los informes y memos.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 179
Las metodologías estructuradas fomentan los métodos estructurados de recopilación de datos. Por lo gene-
ral se utilizan técnicas estructuradas para estructurar las entrevistas y diseñar el proceso de las mismas. Hay que
desarrollar los cuestionarios de una manera estructurada; además las técnicas observacionales estructuradas tales
como STROBE podrán animar al analista a observar de manera específica los elementos clave para formar con-
clusiones con base en las observaciones del entorno físico. Se determinaría un plan de muestreo en forma cuanti-
tativa, para que el analista de sistemas pudiera seleccionar los informes y memos que va a examinar.
Las búsquedas de conocimiento son menos estructuradas en el entorno del modelado ágil. La práctica de
tener un cliente en el sitio mejora en forma considerable el acceso a la información. El cliente en el sitio está
presente para responder preguntas sobre la misma organización, sus objetivos, las prioridades de sus miembros
y cualquier conocimiento necesario sobre los sistemas de información existentes. A medida que el proyecto
avanza, se hace más clara la imagen de los requerimientos del cliente. Esta metodología parece estar libre de
errores ya que, cuando los desarrolladores de sistemas desean saber algo, simplemente tienen que preguntar. Sin
embargo, la desventaja es que el representante en el sitio tal vez invente información si no la conoce o si no está
a su disposición, o tal vez evite decir la verdad por algún otro motivo oculto.
REDUCCIÓN DE LOS TIEMPOS Y COSTOS DE LA COMUNICACIÓN Y LA COORDINACIÓN La comunicación entre
analistas y usuarios, así como entre los mismos analistas, es la base del desarrollo de sistemas. Sin duda una
mala comunicación es la raíz de múltiples problemas de desarrollo. Sabemos que la comunicación aumenta
cuando se unen más personas al proyecto. Cuando dos personas trabajan en un proyecto, existe la oportunidad de
entablar una conversación cara a cara; cuando hay tres involucradas, hay tres posibilidades; cuando hay cuatro,
hay seis posibilidades y así sucesivamente. Los miembros inexpertos del equipo necesitan tiempo para ponerse al
corriente y pueden ralentizar un proyecto incluso aunque traten de ayudar a agilizarlo.
El desarrollo estructurado tradicional fomenta la separación de tareas extensas en tareas más pequeñas. Esto
permite que haya grupos más unidos y reduce el tiempo que se invierte en la comunicación. Otra metodología im-
plica establecer barreras. Por ejemplo, tal vez los clientes no tengan acceso a los programadores. Ésta es una prác-
tica común en muchas industrias. Sin embargo, un aumento en la eficiencia a menudo implica una reducción en la
eficacia, y se ha descubierto que al dividir grupos y establecer barreras se introducen errores con frecuencia.
Por otra parte, los métodos ágiles limitan el tiempo en vez de las tareas. En las metodologías ágiles se utiliza
el concepto de cajas de tiempo (timeboxing) para fomentar la terminación de actividades en periodos más cortos.
Usar una caja de tiempo es simplemente establecer un límite de tiempo de una o dos semanas para completar una
característica o módulo. Scrum, del método ágil, impone una prima sobre el tiempo, mientras que los desarrolla-
dores se comunican de manera efectiva como equipo. Como la comunicación es uno de los cuatro valores de la
filosofía ágil, los costos de comunicación tienden a aumentar en vez de disminuir.
REDUCCIÓN DE LAS PÉRDIDAS DEBIDO A LA SOBRECARGA HUMANA DE INFORMACIÓN Desde hace tiempo
sabemos que las personas no reaccionan bien en situaciones de sobrecarga de información. Cuando los teléfonos
eran una tecnología emergente, los operadores de los conmutadores conectaban en forma manual las llamadas
entre dos partes. Se llegó a demostrar que este sistema funcionaría hasta que ocurriera una sobrecarga de
información, punto en el cual todo el sistema fallaba. Cuando llegaban demasiadas llamadas, el abrumado
operador del conmutador simplemente dejaba de trabajar y se rehusaba a realizar las conexiones. Una situación
de sobrecarga parecida le puede ocurrir a cualquier persona en cualquier momento, incluyendo a los analistas de
sistemas y a los programadores.
Una metodología tradicional sería tratar de filtrar información para proteger a los analistas y programadores
de las quejas de los clientes. Esta metodología permite a los desarrolladores seguir trabajando en el problema sin
la interferencia y subjetividad que existirían en una situación normal.
Mediante el uso de una filosofía ágil, los analistas y programadores se deben apegar a una semana de trabajo
de 40 horas. Algunos podrían ver esto como una práctica cuestionable. ¿Podrán terminar alguna vez con todo el
trabajo? No obstante, la filosofía ágil establece que el trabajo de calidad se realiza por lo general durante un ho-
rario de rutina, y es sólo al momento de agregar tiempo extra cuando entran a la escena los problemas de diseño
y programación de mala calidad. Al apegarse a un programa de una semana de trabajo de 40 horas, la metodolo-
gía ágil afirma que en un momento dado usted saldrá adelante.
Riesgos inherentes a la innovación organizacional
Al consultar con los usuarios, los analistas deben considerar los riesgos a los que se enfrentan las organizaciones
al adoptar nuevas metodologías. Sin duda esto está relacionado con el momento apropiado para actualizar las
habilidades humanas, adoptar nuevos procesos organizacionales e instituir el cambio interno.
En un sentido más amplio, éstas son preguntas de dimensión estratégica para el liderazgo organizacional.
Consideremos de manera específica el caso del equipo de análisis de sistemas que adopta los métodos ágiles en
virtud de los riesgos para la organización y el resultado exitoso eventual para el equipo de desarrollo de sistemas
y sus clientes. En la figura 6.11 se muestran muchas de las variables que debemos considerar al evaluar el riesgo
de adoptar una innovación organizacional.www.xlibros.com

180 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
Medición del
impacto Costo
Riesgos
inherentes a la
innovación
organizacional
Derechos
individuales Sincronización
Cultura de
la organización
Reacciones de
los clientes
FIGURA 6.11
Para adoptar nuevos sistemas de
información hay que buscar el
equilibrio entre varios riesgos.
CULTURA DE LA ORGANIZACIÓN Una consideración clave es la cultura en general de la organización y cómo
encaja en ella la cultura del equipo de desarrollo. Una cultura organizacional conservadora con muchas
características estables que no busque innovar puede ser un contexto inapropiado, e incluso inhóspito, para
que el grupo de desarrollo de sistemas adopte las metodologías ágiles. Los analistas y otros desarrolladores
deben tener cuidado al introducir nuevas técnicas en este tipo de entorno, ya que su éxito dista mucho de estar
asegurado; además los miembros de mucho tiempo del equipo de desarrollo u otros miembros de la organización
pueden sentirse amenazados por las nuevas formas de trabajar que difieren de las metodologías acostumbradas y
confiables, que han producido resultados comprobados.
En contraste, una organización que depende de la innovación para retener su ventaja competitiva en su in-
dustria podría ser la que esté en mejor condición de aceptar las innovaciones ágiles en los métodos de desarrollo
de sistemas. En este caso, la cultura de la organización ya está impregnada con el entendimiento de la naturaleza
crítica de muchos de los principios básicos de las metodologías de desarrollo ágil. Desde del nivel estratégico
hacia abajo, los miembros de la empresa han interiorizado la necesidad de tener una retroalimentación rápida,
respuestas dinámicas a los entornos cambiantes en tiempo real, depender del cliente para que actúe como guía y
participe en la solución de problemas, etcétera.
Entre estos dos extremos se encuentran las organizaciones que no dependen de la innovación como fortaleza
estratégica clave (en otras palabras, no dependen de la investigación y desarrollo de nuevos productos o servicios
para seguir a flote) pero que tal vez les convendría la adopción de prácticas innovadoras en pequeñas unidades o
grupos. Es evidente que esos pequeños centros o núcleos innovadores podrían en un momento dado impulsar el
crecimiento o la ventaja competitiva de este tipo de organización.
SINCRONIZACIÓN Las organizaciones deben hacer y responder la pregunta acerca de cuándo es el mejor momento
para innovar con la adopción de nuevas metodologías de desarrollo de sistemas, cuando se tienen en cuenta todos
los proyectos y factores (internos y externos). Las organizaciones deben tener en cuenta toda la variedad de
proyectos en los que están invirtiendo, mirar más allá de los tiempos de entrega de los proyectos, programar la
actualización de las plantas físicas y absorber las proyecciones clave en la industria y la economía.
COSTO Otro de los riesgos en cuanto a la adopción de metodologías ágiles para las organizaciones es el costo
involucrado en la educación y capacitación de los analistas de sistemas y programadores en relación con la
nueva metodología. Esto puede implicar costos de seminarios y cursos fuera del sitio de trabajo, o tal vez haya
que contratar consultores para que trabajen con el personal actual en el sitio. Además hay costos de oportunidad
involucrados cuando los desarrolladores de sistemas se tienen que desviar por necesidad (aunque en forma
temporal) de los proyectos existentes para aprender nuevas habilidades. La educación en sí puede ser costosa,
pero hay que reconocer además la carga adicional que se genera cuando los analistas no pueden obtener ingresos
durante su periodo de capacitación.
REACCIONES DE LOS CLIENTES Cuando los clientes (ya sean internos o externos) se involucran como usuarios o
iniciadores de los esfuerzos de desarrollo de sistemas de información, las reacciones en cuanto al uso de nuevoswww.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 181
métodos requeridos por la metodología ágil también son una consideración clave. Algunos clientes reaccionan de
manera alegre una vez que se les describen los beneficios de la conveniencia en tiempo y la participación. Otros
no quieren que los utilicen para los “experimentos” de sistemas con resultados inciertos. La relación entre cliente
y analista debe ser lo bastante elástica como para absorber y adaptarse a los cambios en los comportamientos
esperados. Por ejemplo, la presencia de un cliente en el sitio durante el desarrollo es un compromiso importante,
por lo que las personas que piensen adoptar metodologías ágiles deben comprenderlo con claridad y estar
completamente de acuerdo.
MEDICIÓN DEL IMPACTO Otra consideración para las organizaciones que adoptan metodologías ágiles es cómo
certificar y medir que los nuevos métodos van a facilitar el desarrollo exitoso de sistemas. Las fortalezas y
debilidades de los métodos estructurados tradicionales que se utilizan para desarrollar sistemas de información
son muy conocidas.
Aunque hay mucha evidencia anecdótica para establecer que las metodologías ágiles son superiores para el
desarrollo bajo ciertas condiciones, su historial es corto y aún no se cuenta con soporte empírico. Por lo tanto, la
adopción de metodologías ágiles conlleva el riesgo de que los sistemas creados con este tipo de metodologías no
sean exitosos, o que no se puedan interconectar en forma adecuada con los sistemas heredados. Ha empezado el
proceso de medir el impacto en cuanto al uso de las metodologías ágiles, pero las organizaciones necesitan estar
alertas al proponer las mediciones del impacto junto con la adopción de nuevos métodos.
LOS DERECHOS INDIVIDUALES DE LOS PROGRAMADORES/ANALISTAS Los desarrolladores (analistas y programa-
dores) de sistemas exitosos ejercen creatividad en cuanto a la forma de llevar a cabo su trabajo, por lo cual
merecen el derecho de trabajar en la configuración más fructífera posible. Es posible que los requerimientos de
trabajo de los nuevos métodos ágiles (por ejemplo, la programación en pareja) vayan en detrimento de ciertos
derechos básicos de las personas creativas de trabajar por su cuenta o en grupos, según lo que dicte el trabajo
de diseño. No hay una “mejor manera” de diseñar un sistema, módulo, interfaz, formulario o página Web. En el
caso de los desarrolladores de sistemas, hay que comparar la creatividad, la subjetividad y el derecho de lograr
los objetivos de diseño por medio de numerosas rutas individuales con las metodologías innovadoras que adopta
la organización, como las metodologías ágiles.
Como podemos ver, la adopción de innovaciones organizacionales es un proceso que impone muchos ries-
gos tanto para la organización como para los individuos. Aquí examinamos los riesgos para la organización en
general, así como los riesgos que corre el analista de sistemas individual que se ve atrapado en el deseo de la
organización de innovar.
La creación de prototipos es una técnica de recopilación de
información útil para complementar el SDLC tradicional; tanto
los métodos ágiles como la interacción humano-computadora
comparten sus raíces en los prototipos. Cuando los analistas de
sistemas utilizan prototipos buscan reacciones de los usuarios,
sugerencias, innovaciones y planes de revisión para realizar
mejoras al prototipo y por ende modificar los planes del sistema
con un mínimo de costo y de interrupciones. Los cuatro linea-
mientos principales para desarrollar un prototipo son: 1) trabajar
en módulos administrables, 2) crear el prototipo con rapidez,
3) modificar el prototipo y 4) hacer énfasis en la interfaz de usuario.
Aunque no siempre es necesario o conveniente usar prototi-
pos, hay que tener en cuenta que existen tres ventajas principales
interrelacionadas en cuanto a su uso: 1) el potencial de cambiar
el sistema durante las primeras etapas de su desarrollo, 2) la
oportunidad de detener el desarrollo en un sistema que no está
funcionando y 3) la posibilidad de desarrollar un sistema que
se acerque más a las necesidades y expectativas de los usuarios.
Éstos tienen que desempeñar un papel definido en el proceso de
creación de prototipos, por lo que los analistas de sistemas deben
trabajar en forma sistemática para obtener y evaluar las reaccio-
nes de los usuarios en relación con el prototipo.
Un uso específico de los prototipos es el desarrollo rápido de
aplicaciones (RAD). Ésta es una metodología orientada a obje-
tos con tres fases: planeación de requerimientos, taller de diseño
RAD e implementación.
El modelado ágil es una metodología de desarrollo de soft-
ware que define un plan general con rapidez, desarrolla y entrega
el software rápidamente y después revisa el software en forma
continua para agregar características adicionales. Los valores
de la metodología ágil que comparten tanto el cliente como el
equipo de desarrollo son comunicación, simpleza, retroalimenta-
ción y valentía. Las actividades ágiles son codificación, prueba,
escucha y diseño. Los recursos disponibles son tiempo, costo,
calidad y alcance.
Las prácticas ágiles diferencian a los métodos ágiles, in-
cluyendo un tipo de método ágil conocido como programación
extrema (XP), de los otros procesos de desarrollo de sistemas.
Las cuatro prácticas básicas de la metodología ágil son 1) entre-
gas pequeñas, 2) semana de trabajo de 40 horas, 3) cliente en el
sitio y 4) programación en pareja. El proceso de desarrollo ágil
incluye elegir una tarea que esté directamente relacionada con
una de las características deseadas del cliente con base en las his-
torias de usuarios, elegir un socio de programación, seleccionar y
escribir los casos de prueba apropiados, escribir el código, ejecu-
tar los casos de prueba, depurar el código hasta que se ejecuten
todos los casos de prueba, implementarlo con el diseño existente
e integrarlo a lo que ya existe.
RESUMENwww.xlibros.com

182 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
E X P E R I E N C I A D E H Y P E R C A S E ® 6
“ Gracias a Dios que es la época del año en donde todo es
nuevo. Me encanta la primavera, es el momento más estimulante
aquí en MRE. Los árboles están tan verdes, con hojas de tantas to-
nalidades. Hay tantos proyectos por hacer, también. Tantos clientes.
Y además tenemos una nueva empleada, Anna Mae Silver. Algunas
veces el empleado más nuevo es el más dispuesto a ayudar. Llámela
si necesita más respuestas”.
“Toda esta novedad me recuerda a los prototipos. O más bien, a
lo que sé sobre ellos. Es algo nuevo y fresco, una manera rápida de
averiguar lo que ocurre”.
“Creo que tenemos unos cuantos prototipos que ya iniciamos.
Algunas veces nuestro nuevo cliente en el sitio, Tessa Silverstone, se
involucra en el proceso de ayudar a crear historias de usuarios con base
en las cuales se construyen los prototipos. Pero lo mejor sobre ellos es
que pueden cambiar. No conozco a nadie que haya estado realmente
satisfecho con el primer intento de uso de un prototipo. Pero es diver-
tido involucrarse con algo que ocurre rápido y que puede cambiar”.
Preguntas de HYPERCASE
1. Elabore una lista de las historias de usuarios que Tessa
Silverstone compartió como ejemplos.
2. Localice el prototipo actual propuesto para usarlo en uno de
los departamentos de MRE. Sugiera unas cuantas
modificaciones que podrían hacer a este prototipo incluso
más sensible en cuanto a las necesidades de la unidad.
3. Use un procesador de palabras para construir un prototipo no
operacional de un Sistema de informes de proyectos de la
unidad de capacitación (Training Unit Project Reporting
System). Incluya las características expuestas por las
historias de usuarios que encontró. Sugerencia: Vea las
pantallas de ejemplo en los capítulos 11 y 12 para que le
ayuden en su diseño.
FIGURA 6.HC1
Una de las diversas pantallas de prototipos que se incluyen en HyperCase.
En las últimas secciones de este capítulo comparamos
cómo las metodologías SDLC y ágil manejan el proceso de
mejorar la eficiencia en el trabajo del conocimiento de una
manera distinta. Después vimos varios peligros inherentes para
las organizaciones que adoptan metodologías innovadoras, in-
cluyendo una cultura organizacional incompatible, una mala
sincronización del proyecto, el costo de la capacitación para los
analistas de sistemas, las reacciones desfavorables de los clien-
tes en cuanto a las nuevas expectativas de comportamiento, las
dificultades para medir el impacto y la posibilidad de compro-
meter los derechos creativos individuales de los programadores
y analistas.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 183
PALABRAS CLAVE Y FRASES
adoptar el cambio
asumir simpleza
cambio incremental
cliente en el sitio
desarrollo rápido de aplicaciones (RAD)
entrega pequeña
fase de planeación de requerimientos
hacer énfasis en la interfaz de usuario
historias de usuarios
implementación
metodología scrum
modelado ágil
modificar el prototipo
participación del usuario en la creación de prototipos
principios ágiles
programación en pareja
programación extrema (XP)
prototipo
prototipo de características seleccionadas
prototipo de parches
prototipo no operacional
prototipo primero de una serie
retroalimentación rápida
semana de trabajo de 40 horas
taller de diseño RAD
trabajar en módulos administrables
valores ágiles
PREGUNTAS DE REPASO
1. ¿Cuáles son los cuatro tipos de información que busca el analista por medio de la creación de prototipos?
2. ¿Qué significa el término prototipo de parches?
3. Defina un prototipo que sea un modelo a escala no funcional.
4. Dé un ejemplo de un prototipo que sea un primer modelo a escala completa.
5. Defina lo que significa un prototipo que es un modelo con ciertas características esenciales, pero no todas.
6. Haga una lista de las ventajas y desventajas de usar prototipos para sustituir el SDLC tradicional.
7. Describa cómo se pueden usar los prototipos para mejorar el SDLC tradicional.
8. ¿Cuáles son los criterios para decidir si debemos crear el prototipo de un sistema?
9. Haga una lista de los cuatro lineamientos que debe observar el analista al desarrollar un prototipo.
10. ¿Cuáles son los dos principales problemas implicados en la creación de prototipos?
11. Haga una lista de las tres principales ventajas de usar prototipos.
12. ¿Cómo puede un prototipo montado en un sitio Web interactivo facilitar el proceso de creación del mismo? Responda en
un párrafo.
13. ¿Cuáles son las tres formas en que puede ayudar un usuario en el proceso de creación del prototipo?
14. Defina lo que significa RAD.
15. ¿Cuáles son las tres fases del RAD?
16. ¿Cuáles son los cuatro valores que deben compartir el equipo de desarrollo y los clientes de la empresa al utilizar una
metodología ágil?
17. ¿Qué son los principios ágiles? Mencione cinco ejemplos.
18. ¿Cuáles son las cuatro prácticas básicas de la metodología ágil?
19. Mencione las cuatro variables de control de recursos que se utilizan en la metodología ágil.
20. Describa los pasos comunes en un episodio de desarrollo ágil.
21. ¿Qué es una historia de usuario? ¿Debe ser escrita o hablada? Indique su opción y después defienda su respuesta con un
ejemplo.
22. Haga una lista de las herramientas de software que pueden ayudar al desarrollador a realizar una variedad de pruebas de
código.
23. ¿Qué es la scrum?
24. Nombre las siete estrategias para mejorar la eficiencia en el trabajo del conocimiento.
25. Identifique seis riesgos al adoptar una innovación organizacional.
PROBLEMAS
1. Como parte de un proyecto grande de sistemas, el banco Clone Bank de Clone, Colorado, quiere que usted los ayude a
establecer un nuevo formulario de informes mensual para sus clientes de las cuentas de cheques y de ahorros. El
presidente y vicepresidente están muy de acuerdo con lo que dicen los clientes en la comunidad: piensan que sus clientes
desean un resumen de su cuenta de cheques que se parezca al que ofrecen los otros tres bancos de la ciudad. Sin
embargo, no están dispuestos a comprometerse a realizar ese formulario sin un resumen formal de retroalimentación de
los clientes que respalde su decisión. La retroalimentación no se utilizará para cambiar el prototipo del formulario de
ninguna manera. Ellos quieren que usted envíe un prototipo de un formulario a un grupo y que envíe el formulario
anterior a otro grupo.
a. En un párrafo describa por qué tal vez no valga la pena crear un prototipo del nuevo formulario bajo estas
circunstancias.
b. En un segundo párrafo describa una situación en la que sería conveniente crear un prototipo de un nuevo formulario.www.xlibros.com

184 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
2. C. N. Itall ha sido analista de sistemas para la empresa Tun-L Vision Corporation durante muchos años. Cuando usted
llegó para formar parte del equipo de análisis de sistemas y sugirió la creación de prototipos como parte del SDLC para
un proyecto actual, C.N. dijo: “Seguro, pero no puedes poner atención a lo que dicen los usuarios. No tienen idea de lo
que quieren. Voy a crear el prototipo, pero no voy a ‘observar’ a los usuarios”.
a. Con el mayor tacto posible para no molestar a C. N. Itall, haga una lista de las razones que respaldan la importancia
de observar las reacciones de los usuarios, las sugerencias y las innovaciones en el proceso de creación del prototipo.
b. En un párrafo describa qué podría ocurrir si se crea el prototipo de una parte de un sistema y no se incorpora
retroalimentación de los usuarios al sistema sucesivo.
3. “Cada vez que creo que he terminado de capturar los requerimientos de información de los usuarios, ya cambiaron de
nuevo. Es como tratar de pegarle a un objetivo móvil. Creo que, la mitad del tiempo, ni ellos mismos saben lo que
quieren”, exclama Flo Chart, analista de sistemas para 2 Good 2 Be True, una empresa que realiza encuestas sobre el uso
de los productos para las divisiones de marketing de varias empresas de manufactura.
a. En un párrafo explique a Flo Chart cómo le pueden ayudar los prototipos para definir mejor los requerimientos de
información de los usuarios.
b. En un párrafo comente acerca de la observación de Flo: “Creo que, la mitad del tiempo, ni ellos mismos saben lo
que quieren”. Asegúrese de explicar cómo pueden los prototipos ayudar a que los usuarios comprendan mejor y
articulen sus propios requerimientos de información.
c. Sugiera cómo podría un prototipo integrado en un sitio Web interactivo resolver las preocupaciones de Flo acerca de
cómo capturar los requerimientos de información de los usuarios. Use un párrafo.
4. Harold, gerente de distrito para la cadena de varias tiendas de nombre Sprocket’s Gifts, piensa que construir un prototipo
sólo puede significar una cosa: un modelo a escala no funcional. También cree que este método es demasiado torpe para
crear prototipos de sistemas de información y por lo tanto se rehúsa a usarlo.
a. Haga una breve comparación (en dos o tres párrafos) y contraste los otros tres tipos de creación de prototipos
posibles, de manera que Harold pueda comprender bien lo que significa la creación de un prototipo.
b. Harold tiene la opción de implementar un sistema, probarlo y después instalarlo en otras cinco ubicaciones de
Sprocket si tiene éxito. Nombre un tipo de prototipo que se ajustaría bien a esta metodología; defienda su elección
en un párrafo.
5. “¡He tenido la idea del siglo!” proclama Bea Kwicke, un nuevo analista de sistemas en el grupo de sistemas que usted
dirige. “Saltemos toda esta basura del SDLC y hagamos un prototipo de todo. Nuestros proyectos avanzarán más rápido,
ahorraremos tiempo y dinero, y todos los usuarios se sentirán como si les pusiéramos atención en vez de alejarnos por
meses sin hablarles”.
a. Haga una lista de las razones que usted (como miembro del mismo equipo que Bea) daría a Bea para persuadirla de
desechar el SDLC y crear un prototipo de cada proyecto.
b. Bea está muy decepcionada con lo que usted dijo. Para animarla, use un párrafo para explicar las situaciones que
usted considere que se presten para crear un prototipo.
6. El siguiente comentario se escuchó en una reunión entre los gerentes y el equipo de análisis de sistemas en la empresa
de mallas y cercas Fence-Me-In: “Ustedes nos dijeron que el prototipo estaría terminado hace tres semanas. ¡Todavía lo
estamos esperando!”.
a. Comente en un párrafo sobre la importancia de la entrega rápida del prototipo de una parte de un sistema de
información.
b. Haga una lista de los tres elementos del proceso de creación de prototipos que haya que controlar para asegurar una
entrega oportuna del prototipo.
c. ¿Cuáles son algunos elementos del proceso de creación de prototipos que sean difíciles de manejar? Haga una lista.
7. Prepare una lista de actividades a realizar por un equipo de desarrollo de sistemas para un agente de viajes en línea que
quiere establecer un sitio Web para sus clientes. Ahora suponga que se le acaba el tiempo. Describa algunas de sus
opciones. Describa las concesiones que tendrá qué realizar para poder entregar el sitio Web a tiempo.
8. Dada la situación para los chocolates de WilliWonk’s (problema 1 en el capítulo 3), ¿cuáles de las cuatro variables de
recursos de modelado ágil se pueden ajustar?
9. Examine la colección de historias de usuarios del comerciante en línea que aparece anteriormente en el capítulo. A la
tienda de medios en línea le gustaría ahora que usted agregara algunas características a su sitio Web. Con base en el
formato que se mostró anteriormente en este capítulo en la figura 6.9, escriba una historia de usuario para las
características que se enlistan a continuación:
a. Incluir anuncios desplegables.
b. Ofrecer al cliente la posibilidad de compartir con sus amigos los detalles de sus compras.
c. Extender la oferta de comprar otros artículos.
10. Vaya al sitio Web de herramientas de Palm en www.palmgear.com. Explore el sitio Web y escriba una docena de
historias de usuario breves para mejorar el sitio Web.
11. Vaya al sitio Web de iTunes y escriba una docena de historias de usuario breves para mejorar el sitio Web.
12. Use las historias que escribió para el problema 9; recorra las cinco etapas del proceso de desarrollo ágil y describa lo que
ocurre en cada una de las etapas.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 185
PROYECTOS EN GRUPO
1. Divida a su grupo en dos subgrupos más pequeños. Haga que el grupo 1 siga los procesos especificados en este capítulo
para crear prototipos. Mediante el uso de una herramienta CASE o un procesador de texto, el grupo 1 debe idear dos
pantallas para un prototipo no operacional en las que utilice la información recolectada en las entrevistas con los
empleados de Maverick Transport que se realizaron en el ejercicio en grupo del capítulo 4. Haga todas las suposiciones
necesarias para crear dos pantallas para los despachadores de camiones. El grupo 2 (que representará a los
despachadores) debe reaccionar a las pantallas del prototipo y proveer retroalimentación sobre los elementos que desean
agregar y los que desean quitar.
2. Los miembros del grupo 1 deberían revisar las pantallas del prototipo con base en los comentarios que recibieron de los
usuarios. Los del grupo 2 deberán responder con comentarios sobre qué tan bien se resolvieron las cuestiones iniciales
con los prototipos refinados.
3. Como grupo unido, escriba un párrafo en el que describa sus experiencias con la creación de prototipos para obtener los
requerimientos de información.
4. Dentro de su grupo, asigne uno de los roles que desempeñan las personas en el desarrollo ágil. Asegúrese de que una
persona sea un cliente en el sitio y que por lo menos dos personas sean programadores. Asigne otros roles, según le parezca
apropiado. Simule la situación de desarrollo de sistemas que describimos en el problema 7, o haga que la persona que
actúe como cliente en el sitio seleccione una empresa de comercio electrónico que le sea familiar. Suponga que el cliente
desea agregar cierta funcionalidad a su sitio Web. Monte una escena en la que muestre lo que haría cada persona si esto
se fuera a manejar con los métodos ágiles. Escriba un párrafo en el que describa las restricciones a las que se enfrenta
cada persona en cuanto a desempeñar su papel.
BIBLIOGRAFÍA SELECCIONADA
Alavi, M. “An Assessment of the Prototyping Approach to Information Systems Development”. Communications of the ACM,
Vol. 27, Núm. 6, junio 1984, pp. 556-563.
Avison, D. y D. N. Wilson. “Controls for Effective Prototyping”. Journal of Management Systems, Vol. 3, Núm. 1, 1991.
Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley Publishing Co., 2000.
Beck, K y M. Fowler. Planning Extreme Programming. Boston: Addison-Wesley Publishing Co., 2001.
Cockburn, A. Agile Software Development. Boston: Addison-Wesley Publishing Co., 2002.
Davis, G. B. y J. D. Naumann. “Knowledge Work Productivity”. En Emerging Information Technologies: Improving Decisions,
Cooperation, and Infrastructure. Editado por K. E. Kendall, pp. 343-357. Thousand Oaks, CA: Sage, 1999. 42.
Davis, G. B. y M. H. Olson. Management Information Systems: Conceptual Foundations, Structure, and Development, 2da.
Edición. Nueva York: McGraw-Hill, 1985.
Fitzgerald, B. y G. Hartnett. “A Study of the Use of Agile Methods Within Intel”. En Business Agility & IT Diffusion. Editado
por L. Matthiassen, J. Pries-Heje y J. DeGross, pp. 187-202. Proc Conference, Atlanta, mayo 2005. Nueva York: Springer,
2005.
Ghione, J. “A Web Developer’s Guide to Rapid Application Development Tools and Techniques”. Netscape World, junio de
1997.
Gremillion, L. L. y P. Pyburn. “Breaking the Systems Development Bottleneck”. Harvard Business Review, marzo-abril 1983,
pp. 130-137.
Harrison, T. S. “Techniques and Issues in Rapid Prototyping”. Journal of Systems Management. Vol. 36, Núm. 6, junio de 1985,
pp. 8-13.
Kendall, J. E. y K. E. Kendall. “Agile Methodologies and the Lone Systems Analyst: When Individual Creativity and Organi-
zational Goals Collide in the Global IT Environment”. Journal of Individual Employment Rights, Vol. 11, Núm. 4, 2004-
2005, pp. 333-347.
Kendall, J. E., K. E. Kendall y S. Kong. “Improving Quality Through the Use of Agile Methods in Systems Development: People
and Values in the Quest for Quality”. En Measuring Information Systems Delivery Quality. Editado por E. W. Duggan y
H. Reichgelt, pp. 201-222. Hershey, PA: Idea Group Publishing, 2006.
Liang, D. Rapid Java Application Development Using JBuilder 3. Upper Saddle River, NJ: Prentice Hall, 2000.
McBreen, P. Questioning Extreme Programming. Boston: Addison-Wesley Publishing Co., 2003.
Naumann, J.D. y A. M. Jenkins. “Prototyping: The New Paradigm for Systems Development”, MIS Quarterly, septiembre 1982,
pp. 29-44.www.xlibros.com

186 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
E P I S O D I O 6
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Tiempo de reacción
“Necesitamos conocer parte de la salida que necesitan los usuarios”, comenta Anna. “Nos ayudará a reafirmar algunas de nues-
tras ideas sobre la información que requieren”.
“De acuerdo”, contesta Chip. “También nos ayudará a determinar la entrada necesaria. A partir de ahí podemos diseñar las
correspondientes pantallas de entrada de datos. Vamos a crear informes y pantallas del prototipo para obtener retroalimentación
de los usuarios. ¿Por qué no usamos Microsoft Access para crear rápidamente pantallas e informes? Yo estoy bastante familia-
rizado con el software. Empecemos por escribir algunas historias ágiles para sintetizar lo que se necesita y después desarrollar
algunos prototipos. También podemos usar los requerimientos de los usuarios y deberíamos crear un prototipo para cada línea
‘se comunica con’ que conecta a un actor con un caso de uso”.
Anna sonríe y comenta, “Ya escribí las siguientes historias ágiles para el problema del mantenimiento preventivo”. Éstas
son:
1. No hay forma de saber cuándo realizar mantenimiento preventivo en las computadoras de escritorio.
2. Por lo general vamos de sala en sala.
3. Al completar una sala, lo anotamos en una lista.
Anna empieza por desarrollar el prototipo INFORME DE MANTENIMIENTO PREVENTIVO. Con base en las historias
ágiles, se pone a trabajar en la creación del prototipo del informe que, piensa, Mike Crowe necesitará.
“Este informe se debe usar para predecir cuando los equipos deben tener un mantenimiento preventivo”, piensa Anna. “Me
parece que Mike necesitaría saber cuál equipo necesita el servicio, así como cuándo se debe programar éste. Veamos: ¿qué
información identificaría claramente al equipo? El número de inventario, la marca y el modelo; imagino que debemos incluir
la sala y el campus para poder localizarlo rápidamente. Una fecha de mantenimiento calculada indicaría a Mike cuándo hay que
completar el trabajo. ¿En qué secuencia debería estar el informe? Tal vez la más útil sería por ubicación”.
El prototipo del INFORME DE MANTENIMIENTO PREVENTIVO con el informe completo se muestra en la figura
E6.1. Observe que se utilizan los caracteres Xxxxxxx y fechas genéricas para indicar la posición en la que se deben imprimir
los datos. Se incluyen ubicaciones reales de los campus y las salas, así como números de inventario. Son necesarios para que
Microsoft Access pueda realizar la impresión en grupo.
El prototipo del informe se termina pronto. Después de imprimir la copia final, Anna lleva el reporte tanto a Mike Crowe
como a Dot Matricks. Mike Crowe está entusiasmado con el proyecto y desea saber cuándo estará el informe en producción.
Dot está impresionada de manera similar.
Surgen varios cambios. Mike desea un área para escribir la fecha de terminación del mantenimiento preventivo, para poder
usar el informe para reescribir las fechas en la computadora. También sugiere que se cambie el título del informe a INFORME
DE MANTENIMIENTO PREVENTIVO SEMANAL. Los siguientes pasos son modificar el informe del prototipo para reflejar
los cambios recomendados y después hacer que Mike y Dot revisen el resultado.
El informe se modifica y se imprime fácilmente. Dot está complacida con el resultado final. “Éste es en realidad un excelente
método para diseñar el sistema”, comenta. “Es tan agradable sentir que formamos parte del proceso de desarrollo y que nuestras
opiniones cuentan. Estoy empezando a sentirme confiada de que el sistema final será justo lo que siempre hemos querido”.
Mike tiene elogios similares, y comenta: “Esto hará que nuestro trabajo fluya con más uniformidad. Elimina la parte de
tener que adivinar sobre los equipos a los que hay que dar mantenimiento. Y usar la secuencia de sala en sala es una excelente
idea. No tenemos que invertir tanto tiempo en regresar a las salas para trabajar en los equipos”.
Chip hace una observación sobre cada una de estas modificaciones en un Formulario de evaluación del prototipo (como la
figura 6.3 del capítulo). Este formulario ayuda a Chip a organizarse y documenta el proceso de creación del prototipo.
Después, Chip y Anna concentran su atención en la creación de prototipos de las pantallas. “Como me gusta el aspecto de
hardware del sistema, ¿por qué no empezamos a trabajar en el diseño de la pantalla AGREGAR NUEVA COMPUTADORA?”,
pregunta Chip.
“Me parece bien”, responde Anna. “Me enfocaré en los aspectos de software”.
Chip analiza los resultados de las entrevistas detalladas con Dot y Mike. Compila una lista de elementos que cada usuario
necesitaría a la hora de agregar una computadora. Otros elementos, como la información sobre la ubicación y el mantenimiento,
actualizarían el ARCHIVO MAESTRO DE COMPUTADORAS después de instalar el equipo.
“No cabe duda de que definir las tablas de la base de datos ayuda a crear prototipos rápidos”, comenta Chip. “No me tardé
mucho en completar la pantalla. ¿Te gustaría verme probar el prototipo?”.
“Seguro”, le responde Anna. “Ésta es mi parte favorita de la creación de prototipos”.
Chip ejecuta el diseño de la pantalla mientras Anna, Mike y Dot observan. Las listas desplegables y las casillas de verifi-
cación facilitan la introducción de datos precisos.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 187
Informe de mantenimiento preventivo
Semana del 6/1/10
6/1/10 Página 1 de 1
Ubicación
del campus
Ubicación
de la sala
Número y marca
de inventario Modelo Fecha del último
mantenimiento
preventivo
Realizado
Administración central 11111 84004782 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 4/4/10 ____
Administración central 11111 90875039 Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 3/24/10 ____
Administración central 11111 93955411 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 4/4/10 ____
Administración central 11111 99381373 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 3/24/10 ____
Administración central 22222 10220129 Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 3/24/10 ____
Administración central 99999 22838234 Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 3/24/10 ____
Administración central 99999 24720952 Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 3/24/10 ____
Administración central 99999 33453403 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 4/4/10 ____
Administración central 99999 34044449 Xxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 4/4/10 ____
Administración central 99999 40030303 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 4/4/10 ____
Administración central 99999 47403948 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 3/24/10 ____
Administración central 99999 56620548 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 4/4/10 ____
Ciencias computacionales central 22222 34589349 Xxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 3/24/10 ____
Ciencias computacionales central 22222 38376910 Xxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 3/24/10 ____
Ciencias computacionales central 22222 94842282 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 3/24/10 ____
Ciencias computacionales central 99999 339393 Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 4/4/10 ____
Zoología central 22222 11398423 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 3/24/10 ____
Zoología central 22222 28387465 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 4/4/10 ____
Zoología central 99999 70722533 Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 3/24/10 ____
Zoología central 99999 99481102 Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 3/24/10 ____
FIGURA E6.1
Prototipo para el INFORME DE
MANTENIMIENTO
PREVENTIVO. Hay que revisar
este informe.
“Esto me gusta mucho”, dice Dot. “¿Puedo tratar de agregar algunos datos?”.
“Adelante”, contesta Chip. “Trata de agregar datos tanto válidos como inválidos. Y observa los mensajes de ayuda que
aparecen en la parte inferior de la pantalla para indicar lo que se debe introducir. ¿Por qué no pruebas este prototipo por uno o
dos días y regresas conmigo? Entonces realizaré los cambios que recomiendes y te daré el prototipo modificado para que lo
revises”.
Anna regresa a su escritorio y crea el diseño de la pantalla AGREGAR REGISTRO DE SOFTWARE.
Cuando Anna termina el diseño de la pantalla, pide a Cher que pruebe el prototipo. Cher introduce información, revisa los
valores de las listas desplegables y observa los mensajes de ayuda.
“Me gusta mucho el diseño de esta pantalla y su apariencia”, comenta Cher. “Aunque le faltan algunos de los campos que
se incluirían por lo general para introducir un paquete de software, como el tipo de computadora en la que se ejecuta el software,
la memoria requerida y la velocidad del procesador. También me gustarían unos botones para guardar el registro y salir”.
“Puedo hacer todos esos cambios. Una vez que los termine, regresaré contigo”, responde Anna mientras hace algunas
anotaciones para sí misma.
Poco tiempo después. Cher vuelve a probar la pantalla AGREGAR REGISTRO DE SOFTWARE. Ésta incluye todas las
características que requiere. Se puede ver el diseño de la pantalla completa mediante Microsoft Access. Cher observa que hay
una línea que separa la información de software de las entradas de hardware.
Unos cuantos días más tarde, Dot visita a Anna con los cambios sugeridos para el prototipo de AGREGAR NUEVA COMPU-
TADORA. “Revisé esto con Mike y nos gusta lo que vimos, pero tenemos unas sugerencias”, comenta Dot. “Una de las cosas
que faltan es el sistema operativo. Tenemos varias personas técnicas que utilizan varios sistemas operativos. Muchos de los
usuarios de los equipos Mac tienen Windows instalado también, y algunos de los usuarios de Windows tienen sistemas tipo
Linux instalados. Necesitamos incluir varios sistemas operativos en la pantalla AGREGAR NUEVA COMPUTADORA”.www.xlibros.com

188 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
“Vamos a requerir algo de tiempo para actualizar las tablas y los prototipos”, comenta Chip después de una larga pausa.
“Pero esta es la razón por la que usamos ciclos cortos para desarrollar, probar y obtener retroalimentación. Modificaré el pro-
totipo y me pondré en contacto con ustedes cuando termine”.
Después de idear y rediseñar las tablas de la base de datos, el prototipo se modifica y se envía a Mike para su aprobación.
Unos cuantos días después. Mike llega con algo de retroalimentación. “¡Se ve excelente!”, exclama Mike. “Sin embargo, me di
cuenta de que hay algunos requerimientos adicionales que olvidé decirles. Tenemos un programa de renovación en el que se
reemplazan las computadoras después de cierto periodo, que varía según el tipo de equipo y la fecha en que se compró. Cuando
compramos el equipo, estimamos el intervalo de renovación. ¿Podemos agregar el intervalo de renovación a la base de datos y
al prototipo? Podríamos usarlo para calcular la fecha de renovación y explorar en forma periódica el Archivo maestro de compu-
tadoras para detectar todas las computadoras que necesiten renovación”.
Chip empieza a trabajar en las modificaciones. “Este desarrollo ágil es interesante”, dice al tiempo que le sonríe a Anna.
“Puedo ver por qué se utiliza para descubrir los requerimientos”.
La versión final del prototipo de AGREGAR NUEVA COMPUTADORA que se creó con Access se muestra en la figura
E6.2. En la parte superior de la pantalla se colocaron la fecha y hora actuales, así como un título centrado en la pantalla. Las
leyendas de los campos están alineadas a la izquierda en la pantalla. Se incluyeron casillas de verificación para el campo de la garan-
tía, así como una lista desplegable para el tipo de unidad óptica. Se incluyó un subformulario del sistema operativo para selec-
cionar varios sistemas operativos en la porción inferior derecha de la pantalla. Se incluyeron los botones “Agregar registro”
(Add Record) e “Imprimir”.
“Chip, estuve hablando con Dot y mencionó que hay financiamiento para incluir parte de la información en la Web, como
parte del sitio Web para soporte de tecnología en la CPU”, comenta Anna, quitando su vista de la computadora. “He estado
ocupada creando un prototipo para los menús de la página Web y la primera pantalla, una para reportar problemas tecnológicos.
Como resolver problemas es el área de Mike, lo invité junto con Dot para revisar el prototipo. ¿Quieres unirte a la sesión?”.
“Seguro”, responde Chip. “Estoy interesado en trabajar en el diseño de algunas de las páginas Web”.
Poco tiempo después, Mike, Dot y Chip están reunidos con Anna mientras ella demuestra la página Web que se ilustra en
la figura E6.3.
“Me gusta mucho el estilo del menú”, comenta Dot. “El menú principal incluye submenús desplegables en la parte superior
que son fáciles de usar; además me gusta la forma en que se despliegan y cómo cambian de color los elementos del menú al
mover el ratón sobre ellos”.
“Sí, y al tener submenús desplegables debajo del principal para las características de cada opción nos ayuda a encontrar lo
que estamos buscando”, agrega Mike. “Ahora, tengo algunas sugerencias para la página Web en la que se reportan los problemas.
Sería más útil si se moviera el área de selección Categoría del problema (Problem Category) a la parte superior de la página.
Cada tipo de problema se asigna a un técnico distinto, uno que sea más o menos experto en esa área. Necesitamos una casilla
de verificación adicional para identificar si es equipo Macintosh, Windows o software con el que estemos trabajando. El campo
Número de etiqueta (Tag Number) ayuda también. Muchas personas no saben que cada pieza de equipo tiene una pequeña
etiqueta metálica de identificación con un número único de inventario. Hmmm... esa gran área azul parece resaltar demasiado.
Después de todo, es sólo ayuda. Creo que sería mejor reemplazarla con una pequeña imagen”.
FIGURA E6.2
Prototipo para la pantalla
AGREGAR NUEVA
COMPUTADORA (Add New
Computer). Se utilizó Microsoft
Access como la herramienta para
crear el prototipo. Se pueden hacer
mejoras en esta etapa.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 189
FIGURA E6.3
Prototipo para la página Web
SISTEMA DE REPORTE DE
PROBLEMAS. Esta página Web
necesita algunas mejoras.
“Creo que será fácil hacer estos cambios”, comenta Anna.
“Excelente”, responde Mike. “También sería útil incluir el número telefónico de la línea de soporte técnico en la página
Web. Si es una verdadera emergencia, podría agilizar la resolución del problema. Deberíamos agregar un campo de entrada para
el número telefónico del usuario también. Desde luego que podríamos buscarlo en la base de datos, pero tal vez la persona que
reporte el problema se encuentre en un laboratorio de cómputo o en otra ubicación lejos de su oficina”.
“¡Buena idea!” exclama Dot. “Esto va a ser en extremo útil para el cuerpo docente y el personal. Creo que debemos crear
prototipos de todas las páginas Web para el sitio. Sé que las páginas Web pueden cambiar de vez en cuando, pero ¡tratemos de
hacer lo mejor que podamos desde el principio! ¿Por qué no les das un vistazo y nos dices lo que opinas en unos días?”.
Anna mira a Chip y sonríe. “¡Creo que estarás trabajando en el diseño de páginas Web más pronto de lo que pensabas!”.
Unos cuantos días más tarde, Mike regresa con retroalimentación adicional sobre el diseño Web. “Esta página Web se ve
bien”, sonríe Mike, “pero me puso a pensar. Tenemos una imagen de todo el software en cada computadora del laboratorio.
Cuando hay un problema, como un virus o una falla en el disco duro, lo corregimos y volvemos a transferir la imagen al equipo.
Sin embargo, cada laboratorio tiene distintos requerimientos en cuanto al software que debe tener el equipo. Además pregunta-
mos al cuerpo docente si la imagen necesita actualización. Por lo general esto ocurre al final del semestre de primavera y tra-
bajamos en ello durante el verano. ¿Puedes crear unos prototipos de páginas Web para que los revisemos? Uno debería tener
una lista de todo el software, incluyendo los navegadores, detección de virus y demás paquetes estándar que se incluyan para
cada equipo en una sala específica. La otra página Web se usaría para que el cuerpo docente actualizara la lista de imágenes”.
“Vaya, implica mucho trabajo”, responde Anna con una mirada pensativa. “Trabajaremos en ello”.
Anna y Chip continúan trabajando en los prototipos; realizan el diseño, obtienen retroalimentación de los usuarios y mo-
difican el diseño para incluir los cambios. Ahora que han terminado el trabajo, tienen una firme idea de los requerimientos del
sistema.
“Este proyecto está creciendo”, comenta Anna mientras mira la gran cantidad de prototipos que han ensamblado. “No creo
que podamos desarrollar todo el software en el periodo de tiempo asignado”.
“Estoy de acuerdo contigo; pareces tener una buena idea sobre ello”, responde Chip pensativamente. “Sólo tenemos seis
meses para desarrollar el proyecto, incluyendo las páginas Web. Hay mucho código de servidor y JavaScript por escribir”.
Anna baja una pila de formularios de evaluación de prototipos y mira directamente a Chip. “¿Cuáles son nuestras opcio-
nes?”.
Chip toma un momento para reflexionar y responde: “Bueno, comprometer la calidad no es una opción y la fecha de entrega
no se puede modificar. Sólo queda hacer concesiones en cuanto al costo y el alcance”.
“El costo está fijo en cierto modo”, responde Anna. “Dot y Paige dijeron a ciencia cierta que hay tantos proyectos de de-
sarrollo que tenemos que permanecer dentro de nuestro presupuesto”.
“Bueno, eso significa que tendremos que reducir el alcance del proyecto”, dice Chip después de un momento. “Trabajare-
mos en los elementos de alta prioridad primero”.
“¿Qué hay sobre sacrificar una semana de trabajo de 40 horas?”, exclama Anna.
“No es una opción”, sonríe Chip. “Después de todo, ¡es un valor básico!”.www.xlibros.com

190 PARTE II • ANÁLISIS DE LOS REQUERIMIENTOS DE INFORMACIÓN
EJERCICIOS
Elabore una crítica de los prototipos de informes y pantallas para los siguientes ejercicios (E-1 al E-10). Registre los cambios
en una copia del Formulario de evaluación de prototipos Use Microsoft Access para ver los prototipos y después modifique los
prototipos de informes y pantallas con los cambios sugeridos. Imprima los prototipos finales.
Use los siguientes lineamientos como ayuda en el análisis:
1. Alineación de los campos en los informes. ¿Están alineados los campos en forma correcta? ¿Están alineados los encabeza-
dos de las columnas de los informes en forma correcta sobre las columnas? Si el informe tiene leyendas a la izquierda de
los campos de datos, ¿están alineadas en forma correcta (por lo general a la izquierda)? ¿Están alineados los datos en forma
correcta dentro de cada campo de entrada?
2. Contenido del informe. ¿Contiene el informe todos los datos necesarios? ¿Están presentes los totales y subtotales apro-
piados y útiles? ¿Hay totales o datos adicionales que no deban estar en el informe? ¿Están impresos las claves o los sig-
nificados de éstas en el informe (hay que evitar claves, ya que tal vez no presenten información al usuario en forma
clara)?
3. Revise la apariencia visual del informe. ¿Se ve agradable? ¿Se imprimen en grupo los campos repetitivos (es decir, los
datos sólo se deben imprimir una vez, al principio del grupo)? ¿Hay suficientes líneas en blanco entre los grupos para
identificarlos con facilidad?
4. Alineación de datos y leyendas en la pantalla. ¿Están alineadas las leyendas en forma correcta en la pantalla? ¿Están
los datos alineados en forma correcta? ¿Están alineados correctamente los datos dentro de un campo?
5. Apariencia visual de la pantalla. ¿Tiene la pantalla una apariencia visual placentera? ¿Hay suficiente espaciamiento
vertical entre los campos? ¿Hay suficiente espaciamiento horizontal entre las columnas? ¿Están agrupados todos los cam-
pos en forma lógica? ¿Están agrupadas las características como los botones y las casillas de verificación?
6. ¿Contiene la pantalla todos los elementos funcionales necesarios? Busque botones faltantes que podrían ayudar al
usuario a trabajar sin problemas con la pantalla; busque también datos faltantes, datos o campos adicionales innecesarios
que se deban sustituir por una casilla de verificación o lista desplegable.
E-1. El LISTADO DE INVENTARIO DE HARDWARE muestra todas las computadoras personales, ordenadas por campus
y sala.
E-2. El INFORME DE INVERSIÓN DE SOFTWARE se utiliza para calcular el monto total invertido en software.
E-3. El INFORME DE COMPUTADORAS INSTALADAS muestra la información de los equipos instalados.
E-4. El prototipo para el INFORME DE PROBLEMAS DE COMPUTADORAS muestra una lista de todos los equipos orde-
nados en base al costo total de las reparaciones e incluye el número de reparaciones (algunos equipos no tienen un costo
alto, ya que aún se encuentran bajo garantía). Este prototipo se utiliza para calcular el costo total de las reparaciones para
toda la universidad, así como para identificar los equipos con problemas.
E-5. El INFORME DE NUEVO SOFTWARE INSTALADO muestra el número de equipos con cada paquete de software que
están instalados en cada sala de cada campus.
E-6. El INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE muestra una lista de todas las ubicaciones para cada
versión de cada paquete de software.
E-7. La pantalla ELIMINAR REGISTRO DE COMPUTADORA se utiliza para seleccionar las computadoras que se van a
eliminar del sistema. El área de entrada es el campo Número de inventario de hardware (Hardware Inventory Number).
Los demás campos sólo son para fines de visualización, para identificar el equipo. A los usuarios les gustaría la habilidad
de imprimir cada registro antes de eliminarlo. También quieren desplazarse a los registros anterior y siguiente. Sugeren-
cia: examine los campos que se muestran en el informe LISTADO DE INVENTARIO DE HARDWARE.
E-8. Una pantalla INFORMACIÓN DE MANTENIMIENTO DE ACTUALIZACIONES permite a Mike Crowe cambiar la
información de mantenimiento sobre las computadoras personales. Algunas veces éstos son cambios de rutina, como
la FECHA DEL ÚLTIMO MANTENIMIENTO PREVENTIVO o el NÚMERO DE REPARACIONES, pero también
pueden ocurrir otros cambios en forma esporádica, como la expiración de una garantía. Se introduce el NÚMERO DE
INVENTARIO DE HARDWARE y se encuentra el REGISTRO DE COMPUTADORA que coincida. Se muestran la
MARCA y el MODELO para fines de retroalimentación. Así el operador puede cambiar los campos GARANTÍA, IN-
TERVALO DE MANTENIMIENTO, NÚMERO DE REPARACIONES, FECHA DE ÚLTIMO MANTENIMIENTO
PREVENTIVO y COSTO TOTAL DE REPARACIONES. A Mike le gustaría imprimir la información en pantalla, así
como realizar cualquier cambio con facilidad.
E-9. La pantalla PETICIÓN DE UBICACIÓN DE SOFTWARE muestra información sobre las salas y los equipos que contie-
nen software seleccionado. Se introducen el TÍTULO, NÚMERO DE VERSIÓN y SISTEMA OPERATIVO. La porción
de salida de la pantalla debe mostrar la UBICACIÓN DEL CAMPUS, UBICACIÓN DE LA SALA, NÚMERO DE
INVENTARIO DE HARDWARE, NOMBRE DE MARCA y MODELO. Los botones permiten al usuario avanzar al
siguiente registro, al registro anterior, cerrar y salir de la pantalla.www.xlibros.com

CAPÍTULO 6 • MODELADO ÁGIL Y PROTOTIPOS 191
FIGURA E6.4
Prototipo para la página Web
ACTUALIZAR IMAGEN DE
LABORATORIO. Esta página
Web necesita algunas mejoras.
E-10. El prototipo de la página Web ACTUALIZAR IMAGEN DE LABORATORIO se muestra en la figura
E6.4. Revise esta página Web y sugiera cambios.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar una base de datos de muestra de Microsoft Access y de Visible Analyst Project para completar los
ejercicios.www.xlibros.com

www.xlibros.com

193
C A P Í T U L O 7
Uso de diagramas
de flujo de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender la importancia del uso de diagramas de flujo de datos (DFD) lógicos y físicos para
describir gráficamente el movimiento de datos para humanos y sistemas en una organización.
2. Crear, usar y expandir los DFD lógicos para capturar y analizar el sistema actual por medio
de niveles padre e hijo.
3. Desarrollar y expandir DFD lógicos que ilustren el sistema propuesto.
4. Producir DFD físicos con base en los DFD lógicos que desarrolle.
5. Comprender y aplicar el concepto de particionamiento de DFD físicos.
El analista de sistemas requiere la libertad conceptual que los diagramas de
flujo ofrecen; éstos caracterizan gráficamente los procesos y flujos de datos en
un sistema empresarial. En su estado original, los diagramas de flujo de datos
describen con la mayor generalidad posible las entradas, los procesos y las sali-
das del sistema, las cuales corresponden a las del modelo de sistemas general
que vimos en el capítulo 2. Podemos usar una serie de diagramas de flujo de
datos en capas para representar y analizar con detalle los procedimientos del sistema más amplio.
LA METODOLOGÍA DEL FLUJO DE DATOS PARA DETERMINAR
LOS REQUERIMIENTOS HUMANOS
Para que los analistas de sistemas puedan comprender los requerimientos de información de los usua-
rios, deben ser capaces de conceptualizar la forma en que los datos se mueven a través de la organiza-
ción, los procesos o la transformación por la que pasan los datos y las salidas de los mismos. Aunque
las entrevistas y la investigación de datos “duros” proveen una narrativa verbal del sistema, una des-
cripción visual puede cristalizar esta información para los usuarios y analistas de una manera útil.
Por medio de una técnica de análisis estructurado conocida como diagramas de flujo de datos
(DFD), el analista de sistemas puede ensamblar una representación gráfica de los procesos de datos a
través de la organización. Al usar combinaciones de sólo cuatro símbolos, el analista puede crear una
descripción ilustrada de los procesos con el fin de elaborar una documentación sólida para el sistema.
Ventajas de la metodología del flujo de datos
La metodología del flujo de datos tiene cuatro ventajas importantes en comparación con las expli-
caciones narrativas sobre la forma en que se mueven los datos a través del sistema:
1. No hay que comprometerse demasiado pronto con la implementación técnica del sistema.
2. Permite comprender con más detalle la capacidad de interrelación de los sistemas y subsistemas.
3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de diagramas de
flujo de datos.
4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos
necesarios.
P A R T E I I I
El proceso de análisiswww.xlibros.com

194 PARTE III • EL PROCESO DE ANÁLISIS
Entidad
Símbolo Significado Ejemplo
Proceso
Información
nuevo estudiante
Flujo de datos
Almacén de datos D3 Archivo maestro
de estudiantes
Estudiante
2.1
Crear registro
de estudiante
FIGURA 7.1
Los cuatro símbolos básicos que
se utilizan en los diagramas de
flujo de datos, sus significados y
ejemplos.
Tal vez la mayor ventaja recaiga en la libertad conceptual que se obtiene al usar los cuatro símbolos (re-
conocerá tres de ellos del capítulo 2; la próxima subsección sobre las convenciones de los DFD aborda todos).
Ninguno de estos símbolos especifica los aspectos físicos de la implementación. Los DFD se enfocan en el
procesamiento de los datos o en la transformación de los mismos a medida que avanzan a través de varios
procesos. En los DFD lógicos no hay distinción entre los procesos manuales o los automatizados. Tampoco se
describen en forma gráfica los procesos en orden cronológico, sino que, en última instancia, se agrupan entre sí
cuando un análisis posterior indique que es conveniente hacerlo. Se agrupan los procesos manuales; también los
automatizados pueden asociarse entre sí. En una sección posterior veremos más detalles sobre este concepto,
conocido como particionamiento.
Convenciones usadas en los diagramas de flujo de datos
Se utilizan cuatro símbolos básicos para graficar el movimiento de los datos en los diagramas: un cuadrado do-
ble, una flecha, un rectángulo con esquinas redondas y un rectángulo con un extremo abierto (cerrado del lado
izquierdo y abierto del lado derecho), como se muestra en la figura 7.1. Podemos describir en forma gráfica todo
un sistema y numerosos subsistemas al combinar estos cuatro símbolos.
El cuadrado doble se utiliza para describir una entidad externa (otro departamento, una empresa, una
persona o una máquina) que pueda enviar/recibir datos hacia/desde el sistema. La entidad externa, o simple-
mente entidad, también se conoce como origen o destino de los datos, y se considera externa al sistema que
se está describiendo. Cada entidad se identifica con un nombre apropiado. Aunque interactúa con el sistema, se
considera fuera de los límites de éste. Se debe denominar a las entidades con un sustantivo. Se puede utilizar
la misma entidad más de una vez en un diagrama de flujo de datos para evitar cruzar las líneas de flujo de
datos.
La flecha muestra el movimiento de los datos de un punto a otro; la cabeza de la flecha apunta hacia el des-
tino de los datos. Los flujos de datos que ocurren al mismo tiempo se pueden describir mediante el uso de fle-
chas paralelas. Como una flecha representa datos sobre una persona, lugar o cosa, también se debe describir con
un sustantivo.
Se utiliza un rectángulo con esquinas redondas para mostrar la ocurrencia de un proceso de transformación.
Los procesos siempre expresan un cambio o transformación en los datos; por ende, el flujo de datos que sale de
un proceso siempre se identifica de manera distinta al flujo que entra al proceso. Los procesos representan elwww.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 195
trabajo que se realiza en el sistema y se deben denominar mediante el uso de uno de los siguientes formatos. Un
nombre claro facilita la acción de entender lo que el proceso lleva a cabo.
1. Al denominar un proceso de alto nivel, asigne al proceso el nombre de todo el sistema. Por ejemplo,
SISTEMA DE CONTROL DE INVENTARIO.
2. Al denominar un subsistema importante, use un nombre tal como SUBSISTEMA DE INFORME DE
INVENTARIOS o SISTEMA DE CUMPLIMIENTO CON CLIENTES DE INTERNET.
3. Al denominar procesos detallados, use una combinación verbo-sustantivo-adjetivo. El verbo describe el tipo
de actividad, como CALCULAR, VERIFICAR, PREPARAR, IMPRIMIR o AGREGAR. El sustantivo
indica cuál es el resultado principal del proceso, como INFORME o REGISTRO. El adjetivo ilustra la
salida específica que se produce, como PEDIDO PENDIENTE o INVENTARIO. Algunos ejemplos de
nombres de procesos completos son CALCULAR IMPUESTO DE VENTAS, VERIFICAR ESTADO DE
CUENTA DE CLIENTE, PREPARAR FACTURA DE ENVÍO, IMPRIMIR INFORME DE PEDIDOS
PENDIENTES, ENVIAR CONFIRMACIÓN POR EMAIL AL CLIENTE, VERIFICAR SALDO DE
TARJETA DE CRÉDITO y AGREGAR REGISTRO DE INVENTARIO.
Un proceso también debe recibir un número de identificación único que indique su nivel en el diagrama. Más ade-
lante en el capítulo hablaremos sobre esta organización. Puede haber varios flujos de datos que entren y salgan de
cada proceso. Examine los procesos que tengan sólo un flujo entrante y saliente para determinar si no hacen falta
más flujos de datos.
El último símbolo básico que se utiliza en los diagramas de flujo de datos es un rectángulo con un extremo
abierto, el cual representa a un almacén de datos. El rectángulo se dibuja con dos líneas paralelas que se cierran
mediante una línea corta del lado izquierdo y cuyo extremo derecho está abierto. Estos símbolos se dibujan con
la anchura suficiente como para permitir una leyenda de identificación entre las líneas paralelas. En los diagra-
mas de flujo de datos lógicos no se especifica el tipo de almacenamiento físico. En este punto, el símbolo del
almacén de datos muestra sólo un depósito de datos que permite examinar, agregar y recuperar los datos.
El almacén de datos puede representar un almacén manual como un archivero, o un archivo o una base de
datos computarizada. Como los almacenes de datos representan a una persona, lugar o cosa, se denominan con
un sustantivo. Los almacenes de datos temporales, como el papel de borrador o un archivo temporal de computa-
dora, no se incluyen en el diagrama de flujo de datos. Hay que dar a cada almacén de datos un número de refe-
rencia único, como D1, D2, D3, por ejemplo.
CÓMO DESARROLLAR DIAGRAMAS DE FLUJOS DE DATOS
Podemos y debemos dibujar los diagramas de flujos de datos en forma sistemática. En la figura 7.2 se sintetizan
los pasos involucrados para completar con éxito los diagramas de flujos de datos. En primer lugar, el analista de
sistemas necesita conceptualizar los flujos de datos desde una perspectiva de arriba-abajo.
Para empezar un diagrama de flujo de datos, contraiga la narrativa (o historia) del sistema de la organización
en una lista con las cuatro categorías de entidad externa, flujo de datos, proceso y almacén de datos. A su vez,
esta lista ayuda a determinar los límites del sistema que va a describir. Una vez que haya compilado una lista bá-
sica de elementos de datos, empiece a dibujar un diagrama de contexto.
He aquí unas cuantas reglas básicas a seguir:
1. El diagrama de flujo de datos debe tener por lo menos un proceso y no debe haber objetos independientes o
conectados a sí mismos.
2. Un proceso debe recibir por lo menos un flujo de datos entrante y debe crear por lo menos un flujo de datos
saliente.
3. Un almacén de datos debe estar conectado con por lo menos un proceso.
4. Las entidades externas no se deben conectar entre sí. Aunque se comunican en forma independiente, esa
comunicación no forma parte del sistema que diseñamos mediante el uso de DFD.
Creación del diagrama de contexto
Con una metodología arriba-abajo para crear un diagrama del movimiento de los datos, los diagramas avanzan de
generales a específicos. Aunque el primer diagrama ayuda al analista de sistemas a comprender el movimiento
de datos básico, su naturaleza general limita su utilidad. El diagrama de contexto inicial debe ser una vista ge-
neral que incluya las entradas básicas, el sistema general y las salidas. Este diagrama será el más general, una
verdadera vista panorámica del movimiento de datos en el sistema y la conceptualización más amplia posible del
sistema.
El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y contiene sólo un proceso, el
cual representa a todo el sistema. El proceso recibe el número cero. Todas las entidades externas se muestran enwww.xlibros.com

196 PARTE III • EL PROCESO DE ANÁLISIS
1. Hacer una lista de las actividades de la empresa y usarla para determinar
los siguientes elementos:
• Entidades externas
Flujos de datos
Procesos
Almacenes de datos
•
•
•
2. Crear un diagrama de contexto que muestre las entidades externas y
los flujos de datos que entran y salen del sistema. No debe mostrar
procesos detallados ni almacenes de datos.
3. Dibujar el Diagrama 0, el siguiente nivel. Puede mostrar los procesos
pero debe mantenerlos en un nivel general. En este nivel puede mostrar
los almacenes de datos.
4. Crear un diagrama hijo para cada uno de los procesos en el Diagrama 0.
5. Verificar los errores y asegurarse de que las etiquetas que asigne a cada
proceso y flujo de datos sean significativas.
6. Desarrollar un diagrama de flujo de datos físico a partir del diagrama de
flujo de datos lógico. Establecer la diferencia entre los procesos manuales
y los automatizados, describir los archivos e informes actuales por
nombre y agregar controles para indicar cuando se completen los procesos
o se produzcan errores.
7. Particionar el diagrama de flujo de datos físico mediante la separación o
agrupación de partes del diagrama para facilitar la programación y la
implementación.
Cómo desarrollar diagramas de flujo de
datos mediante una metodología arriba-abajo
FIGURA 7.2
Pasos para desarrollar diagramas
de flujo de datos.
el diagrama de contexto, así como el flujo de datos principal que entra y sale de ellas. El diagrama no contiene
almacenes de datos y es bastante simple de crear una vez que los analistas conocen las entidades externas y el
flujo de datos que entra y sale de ellas.
Dibujo del Diagrama 0 (el siguiente nivel)
Podemos obtener más detalles de lo que permite el diagrama de contexto si “expandimos” los diagramas. Las
entradas y salidas especificadas en el primer diagrama permanecen constantes en todos los subsiguientes. Sin
embargo, el resto del diagrama original se expande en acercamientos que incluyan de tres a nueve procesos y
muestren los almacenes de datos, junto con los nuevos flujos de datos de niveles inferiores. El efecto es como
si tomáramos una lupa para ver el diagrama de flujo original. Cada diagrama expandido debe ocupar sólo una
hoja de papel. Al expandir los DFD en subprocesos, el analista de sistemas empieza a llenar los detalles sobre el
movimiento de los datos. El manejo de las excepciones se ignora durante los primeros dos o tres niveles en los
diagramas de flujo de datos.
El Diagrama 0 es la expansión del diagrama de contexto; puede incluir hasta nueve procesos. Si incluimos
más procesos en este nivel obtendremos un diagrama abarrotado de información que será difícil de comprender.
Cada proceso se enumera con un entero, por lo general empezando a partir de la esquina superior izquierda del
diagrama y avanzando hacia la esquina inferior derecha. En el Diagrama 0 se incluyen los principales almacenes
de datos del sistema (que representan a los archivos maestros) y todas las entidades externas. En la figura 7.3 se
ilustra de manera esquemática el diagrama de contexto y el Diagrama 0.
Como un diagrama de flujo de datos es bidimensional (en vez de lineal), tal vez quiera empezar en cualquier
punto y avanzar hacia delante o hacia atrás por el diagrama. Si no está seguro de lo que podría incluir en cual-
quier punto, tome una entidad externa, proceso o almacén de datos distinto y empiece a dibujar el flujo a partir
de él. Usted puede:www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 197
Flujo de
datos C
Entrada B
Entrada A
Salida C
Entrada A
Flujo de
datos B Salida C
Registro A Registro E
Registro A Registro E
Entrada B
Flujo de
datos D
Proceso
general
BBB
Proceso
general
AAA
Proceso
general
CCC
Proceso
general
DDD
Entidad
3
Entidad
3
Entidad
1
Entidad
2
Entidad
1
Entidad
2
0
1 2
3 4
Nombre del
sistema
Almacén de datos 1D1 Almacén de datos 2D2
FIGURA 7.3
Los diagramas de contexto
(superior) se pueden “expandir” en
un Diagrama 0 (inferior). Observe
el mayor detalle en el Diagrama 0.
1. Empezar con el flujo de datos proveniente de una entidad en el lado de entrada. Haga preguntas tales como:
“¿Qué ocurre con los datos que entran al sistema?”, “¿Se guardan?”, “¿Constituyen la entrada para varios
procesos?”.
2. Trabaje en sentido inverso desde un flujo de datos de salida. Examine los campos de salida en un documento
o pantalla (este método es más sencillo si se crearon prototipos). Para cada campo en la salida pregunte lo
siguiente: “¿De dónde proviene?” o “¿Se calcula o se guarda en un archivo?”. Por ejemplo, cuando la salida
es un CHEQUE DE NÓMINA, el NOMBRE DE EMPLEADO y la DIRECCIÓN se ubicarían en un archivo
de EMPLEADO, las HORAS TRABAJADAS estarían en un REGISTRO DE TIEMPO y se calcularían el
SUELDO BRUTO y las DEDUCCIONES. Cada archivo y registro estaría conectado al proceso que produce
el cheque de nómina.
3. Examine el flujo de datos que entra o sale de un almacén de datos. Pregunte: “¿Qué procesos colocan
datos en el almacén?” o “¿Qué procesos utilizan los datos?”. Tenga en cuenta que un almacén de datos
que se utilice en el sistema en el que usted esté trabajando puede ser producido por un sistema distinto.
Por ende, desde su posición de ventaja, tal vez no haya ningún flujo de datos que entre al almacén de
datos.
4. Analice un proceso bien definido. Examine los datos de entrada que necesita el proceso y la salida que
produce. Después conecte la entrada y la salida a los almacenes de datos y las entidades apropiadas.
5. Tome nota de cualquier área confusa en donde no esté seguro de lo que se debería incluir o de la entrada o
salida requerida. Al estar consciente de las áreas problemáticas podrá formular una lista de preguntas para
las entrevistas de seguimiento con los usuarios clave.www.xlibros.com

198 PARTE III • EL PROCESO DE ANÁLISIS
Creación de diagramas hijos (niveles más detallados)
Cada proceso en el Diagrama 0 puede a su vez expandirse para crear un diagrama hijo más detallado. Al proceso
que se expande en el Diagrama 0 se le conoce como el proceso padre, y al diagrama que resulta se le conoce
como el diagrama hijo. La regla principal para crear diagramas hijos es el balanceo vertical; esta regla establece
que un diagrama hijo no puede producir salida o recibir entrada que el proceso padre no produzca o reciba tam-
bién. Todos los datos entrantes o salientes del proceso padre deben mostrarse como entrantes o salientes en el
diagrama hijo.
El diagrama hijo recibe el mismo número que su proceso padre en el Diagrama 0. Por ejemplo, el proceso 3 se
expande en el diagrama 3. Los procesos en el diagrama hijo se enumeran mediante el uso del número del proceso
padre, un punto decimal y un número único para cada proceso hijo. En el diagrama 3 los procesos se enumera-
rían como 3.1, 3.2, 3.3 y así en lo sucesivo. Esta convención permite al analista rastrear una serie de procesos a
través de muchos niveles de explosión. Si el Diagrama 0 describe los procesos 1, 2 y 3, los diagramas hijos 1, 2
y 3 se encuentran todos en el mismo nivel.
Por lo general, las entidades no se muestran en los diagramas hijos debajo del Diagrama 0. El flujo de datos
que concuerda con el flujo padre se denomina flujo de datos de interfaz y se muestra como una flecha que entra
o sale de un área en blanco del diagrama hijo. Si el proceso padre tiene un flujo de datos que lo conecta con un
almacén de datos, el diagrama hijo puede incluir el almacén de datos también. Además, este diagrama de nivel
inferior puede contener almacenes de datos que no se muestren en el proceso padre. Por ejemplo, se puede in-
cluir un archivo que contenga una tabla de información tal como una tabla de impuestos, o un archivo que vincule
dos procesos en el diagrama hijo. Los flujos de datos menores, como una línea de error, se pueden incluir en un
diagrama hijo pero no en el padre.
Los procesos se pueden o no expandir, dependiendo de su nivel de complejidad. Cuando un proceso no se
expande, se dice que es funcionalmente primitivo y se le denomina proceso primitivo. Hay que escribir lógica
para describir estos procesos; veremos esto con detalle en el capítulo 9. En la figura 7.4 se ilustran los niveles
detallados en un diagrama de flujo de datos hijo.
Comprobación de errores en los diagramas
Varios de los errores que se cometen al dibujar diagramas de flujo de datos son:
1. Olvidar incluir un flujo de datos o apuntar una flecha en dirección equivocada. Un ejemplo es dibujar un
proceso que muestra a todos sus flujos de datos como entradas o a todos como salidas. Cada proceso
transforma los datos: debe recibir datos de entrada y producir datos de salida. Por lo general este tipo de
error ocurre cuando el analista olvida incluir un flujo de datos o coloca una flecha apuntando en dirección
equivocada. El proceso 1 en la figura 7.5 sólo contiene una entrada debido a que la flecha de SUELDO
BRUTO apunta en dirección equivocada. Este error también afecta al proceso 2, CALCULAR MONTO A
RETENER, al cual también le falta un flujo de datos que representa la entrada para las tasas de retención y
el número de dependientes.
2. Conectar almacenes de datos y entidades externas directamente entre sí. No se pueden conectar los
almacenes de datos y las entidades entre sí; se deben conectar sólo mediante un proceso. Un archivo no se
interconecta con otro archivo sin la ayuda de un programa o una persona que mueva los datos, por lo cual
ARCHIVO MAESTRO DE EMPLEADOS no puede producir directamente el archivo RECONCILIACIÓN
DE CHEQUES. Las entidades externas no trabajan directamente con archivos. Por ejemplo, no es
conveniente que un cliente hurgue por el archivo maestro de clientes. Por lo tanto, el EMPLEADO no
puede crear el ARCHIVO DE TIEMPO DE EMPLEADOS. Dos entidades externas conectadas en forma
directa indican que desean comunicarse entre sí. Esta conexión no se incluye en el diagrama de flujo
de datos a menos que el sistema facilite la comunicación. La producción de un informe es una instancia de
este tipo de comunicación. Sin embargo, debe haber un proceso interpuesto entre las entidades para
producir el informe.
3. Etiquetar de manera incorrecta los procesos o el flujo de datos. Inspeccione el diagrama de flujo de datos
para asegurar que cada objeto o flujo de datos esté identificado en forma apropiada. Un proceso debe indicar
el nombre del sistema o debe usar el formato verbo-sustantivo-adjetivo. Cada flujo de datos se debe
describir con un sustantivo.
4. Incluir más de nueve procesos en un diagrama de flujo de datos. Al tener muchos procesos se produce un
diagrama sobrecargado de información que puede confundirnos al tratar de leerlo y entorpece la
comunicación en vez de mejorarla. Si hay más de nueve procesos involucrados en un sistema, agrupe
algunos de los procesos que trabajen en conjunto para formar un subsistema y colóquelos en un
diagrama hijo.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 199
Flujo de
datos D
Registro A
Entrada BEntidad
2
3
Flujo de
datos D
Proceso
detallado
YYY
Proceso
detallado
XXX
Proceso
detallado
ZZZ
4
Entrada B
3.1
Registro de
transacciones 1 D5 Archivo de
transacciones 1
Registro de
transacciones 1
Error
3.2
Flujo
de datos
detallado Z
3.3
Registro A
El flujo de datos
del proceso padre
al diagrama hijo
debe coincidir.
Flujo de datos que
coincide.
Se pueden agregar
líneas de error en un
diagrama hijo
detallado.
Se pueden agregar
archivos de transacción
a diagramas de niveles
más bajos.
El flujo de salida
debe coincidir con
el del proceso
padre.
Proceso
general
CCC
Proceso
general
DDD
D1 Almacén
de datos 1
D1 Almacén de datos 1
FIGURA 7.4
Diferencias entre el diagrama padre (superior) y el diagrama hijo (inferior).
5. Omitir el flujo de datos. Examine su diagrama en busca de flujo lineal; es decir, un flujo de datos en el que
cada proceso sólo tiene una entrada y una salida. Excepto en el caso de los diagramas de flujo con datos de
diagramas hijos muy detallados, el flujo de datos lineal ocurre raras veces. Por lo general su presencia indica
que faltan flujos de datos en el diagrama. Por ejemplo, el proceso CALCULAR MONTO DE RETENCIÓN
necesita el número de dependientes que tiene un empleado y las TASAS DE RETENCIÓN como entrada.
Además, no se puede calcular el SUELDO NETO sólo con base en la RETENCIÓN, y el CHEQUE DE
PAGO DEL EMPLEADO no se puede crear sólo a partir del SUELDO NETO; también hay que incluir un
NOMBRE DE EMPLEADO así como las cifras de nómina actuales y del año a la fecha, además del
MONTO DE RETENCIÓN.
6. Crear una descomposición (o expansión) desbalanceada en los diagramas hijos. Cada diagrama hijo debe
tener el mismo flujo de datos de entrada y salida que el proceso padre. La excepción a esta regla es la salida
menor, como las líneas de error que se incluyen sólo en el diagrama hijo. El diagrama de flujo de datos de lawww.xlibros.com

200 PARTE III • EL PROCESO DE ANÁLISIS
Sueldo
neto
Empleado
D2 Archivo de tiempo
de empleados
Registro de tiempo
de empleado
D1 Archivo maestro
de empleados
Horas
trabajadas
Sueldo bruto Retención
Cheque de pago
de empleado
Registro de
empleado
Registro de
empleado
D1 Archivo maestro
de empleados
Registro de
reconciliación
de cheques
D3 Reconciliación de
cheques Empleado
Una entidad externa
no se debe conectar
de manera directa a
un almacén de datos.
Un almacén de datos
no se debe conectar
de manera directa a
otro almacén de
datos.
Calcular
sueldo
bruto
Calcular
monto de
retención
Calcular
sueldo neto
Imprimir
cheque de pago
de empleado
1 2 3
4
El proceso 1 no
tiene salida.
El proceso 2 no tiene
entrada. El flujo de
datos Sueldo bruto
va en dirección
equivocada.
FIGURA 7.5
Errores comunes que pueden
ocurrir en un diagrama de flujo de
datos (ejemplo de nómina).
figura 7.6 está dibujado en forma correcta. Observe que, aunque el flujo de datos no es lineal, podemos
seguir con claridad una ruta directamente desde la entidad de origen hasta la entidad de destino.
DIAGRAMAS DE FLUJO DE DATOS LÓGICOS Y FÍSICOS
Los diagramas de flujo de datos se clasifican como lógicos o físicos. Un diagrama de flujo de datos lógico se
enfoca en la empresa y la forma en que ésta opera. No se preocupa por la forma en que se construirá el sistema,
sino que describe los eventos de la empresa que se llevarán a cabo, además de los datos requeridos y producidos
por cada evento. En contraste, un diagrama de flujo de datos físico muestra cómo se implementará el sistema,
incluyendo hardware, software, los archivos y las personas involucradas en el sistema. La tabla de la figura 7.7
compara las características de los modelos lógicos y físicos. Cabe mencionar que el modelo lógico refleja a la
empresa, mientras que el modelo físico describe al sistema.
Lo ideal es desarrollar sistemas para analizar el sistema actual (el DFD lógico actual) y después agregar las
características que debería incluir el nuevo sistema (la DFD lógica propuesta). Por último hay que desarrollar
los mejores métodos para implementar el nuevo sistema (el DFD físico). En la figura 7.8 se muestra esta progre-
sión.
Al desarrollar un diagrama de flujo de datos lógico para el sistema actual podemos comprender con claridad
la forma en que opera el sistema actual y, por ende, constituye un buen punto de partida para desarrollar el mo-
delo lógico del sistema actual. Como este paso lleva mucho tiempo, a menudo se omite para pasar directamente
al DFD lógico propuesto.
Un argumento a favor de tomarse el tiempo para construir el diagrama de flujo de datos lógico del sistema
actual es que podemos utilizarlo para crear el diagrama de flujo de datos lógico del nuevo sistema. Podemos
quitar los procesos que no serán necesarios en el nuevo sistema y agregar las nuevas características, activida-www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 201
Empleado
D2 Archivo de tiempo
de empleados
Registro
de tiempo
de empleado
D1 Archivo maestro
de empleados
Horas
trabajadas
Sueldo bruto
Registro de
empleado
D1 Archivo maestro
de empleados
Registro de
reconciliación
de cheques
Empleado
Registro de tiempo
de empleado
Número de
dependientes D4 Tablas de
retención
Tasas de
retención
D3 Reconciliación
de cheques
Sueldo
neto
Monto de
retención
Monto de
retención
Sueldo bruto
Sueldo
bruto
Registro de
empleado
Cheque de pago
de empleado
Información de
cheque de pago
Crear registro
de tiempo de
empleado
1
Crear
archivo de
reconciliación
de cheques
6
Calcular
sueldo
bruto
2
Calcular
monto de
retención
3
Calcular
sueldo
neto
4
Imprimir
cheque de
empleado
5
FIGURA 7.6
El diagrama de flujo de datos correcto para el ejemplo de la nómina.
des, procesos de salida, de entrada y datos almacenados. Esta metodología ofrece un medio para asegurar que
se retengan las características esenciales del sistema anterior en el nuevo sistema. Además, al utilizar el modelo
lógico del sistema actual como base para el sistema propuesto podemos realizar una transición gradual hacia el
diseño del nuevo sistema. Una vez desarrollado el modelo lógico del nuevo sistema, podemos usarlo para crear
un diagrama de flujo de datos físico para este nuevo sistema.
En la figura 7.9 aparece un diagrama de flujo de datos lógico y un diagrama de flujo de datos físico para
un cajero de una tienda de abarrotes. El CLIENTE lleva los ARTÍCULOS a la caja registradora; se BUSCAN
los PRECIOS de todos los ARTÍCULOS y después se obtiene el total; después se proporciona el PAGO al ca-
jero; por último, el CLIENTE obtiene un RECIBO. El diagrama de flujo de datos lógico ilustra los procesos
involucrados sin entrar en los detalles sobre la implementación física de las actividades. El diagrama de flujo
de datos físico muestra que se utiliza un CÓDIGO DE BARRAS del código de producto universal (UPC) que
se encuentra en la mayoría de los artículos de la tienda de abarrotes. Además, el diagrama de flujo de datos
físico menciona procesos manuales tales como la exploración, explica que se utiliza un archivo temporal parawww.xlibros.com

202 PARTE III • EL PROCESO DE ANÁLISIS
Característica de diseño Lógico Físico
Qué describe el
modelo
Colecciones de datos
sin importar cómo se
guarden éstos
Muestran los almacenes
de datos que
representan colecciones
permanentes de datos
Cómo se implementará el sistema (o cómo
opera el sistema actual)
Cómo opera
la empresa
Controles del sistema
Tipo de almacenes de
datos
Muestra los controles
de la empresa
Muestra los controles para validar los datos de
entrada, para obtener un registro (estado de
registro encontrado), para asegurar que se
complete un proceso con éxito y para la seguridad
del sistema (ejemplo: registros del diario)
Archivos maestros, archivos de transición.
Cualquier proceso que opere en dos
momentos distintos se debe conectar
mediante un almacén de datos
Archivos y bases de datos físicas,
archivos manuales
Qué representan los
almacenes de datos
Qué representan
los procesos
Actividades de
la empresa
Programas, módulos de programas
y procedimientos manuales
FIGURA 7.7
Características comunes para los
diagramas de flujo de datos
lógicos y físicos.
Diagrama de flujo
de datos lógico
nuevo
Diagrama de flujo
de datos físico
nuevo
Diagrama de
flujo de datos
lógico actual
Para derivar el diagrama de flujo
de datos lógico para el sistema
actual hay que examinar el diagrama
de flujo de datos físico y aislar las
actividades únicas de la empresa.
Para crear el diagrama de flujo de
datos lógico para el nuevo sistema
hay que agregar la entrada, salida y
los procesos requeridos en el nuevo
sistema al diagrama de flujo de datos
lógico para el sistema actual.
Para derivar el diagrama de flujo de
datos físico hay que examinar los
procesos en el nuevo diagrama lógico.
Hay que determinar dónde deben existir
las interfaces de usuario, la naturaleza de
los procesos y los almacenes de datos
necesarios.
FIGURA 7.8
La progresión del modelo
lógico al modelo físico.
mantener un subtotal de artículos e indica que el PAGO se puede realizar mediante EFECTIVO, CHEQUE o
TARJETA DE DÉBITO. Por último, hace referencia al recibo por su nombre, RECIBO DE CAJA REGIS-
TRADORA.
Cómo desarrollar diagramas de flujo de datos lógicos
Para desarrollar un diagrama de este tipo hay que construir primero un diagrama de flujo de datos lógico para el
sistema actual. Hay varias ventajas en cuanto al uso de un modelo lógico:
1. Mejor comunicación con los usuarios.
2. Sistemas más estables.
3. Los analistas comprenden mejor el funcionamiento de la empresa.
4. Flexibilidad y mantenimiento.
5. Se eliminan las redundancias y se facilita la creación del modelo físico.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 203
Artículos y precios
Cliente
Identificar
artículo
1
D1 Precios
Artículos por
comprar
Precios
Buscar
precios
2
ID de artículo Cantidad a pagarCalcular el
costo total
del pedido
3
Recibo
Saldar
transacción y
emitir recibo
4
Cliente
Pago
Diagrama de flujo de datos lógico
Códigos y precios
de artículos
Cliente
Pasar
artículo por
el escáner
(manual)
1
D1 Archivo de precios UPC Archivo de trans.
temporal
Artículos
a pagar
Descripción y precios
del artículo
Buscar código
y precio en
el archivo
2
Código de
barras UPC
Monto calculado
a pagarCalcular
costo
total
3
Recibo
de la caja
registradora
Recibir dinero
y dar
recibo
(manual)
4
Cliente
Efectivo,
cheque o
tarjeta de
débito
Diagrama de flujo de datos físico
Código UPC
D2
Artículos, precios
y subtotales
Artículos y
precios FIGURA 7.9
El diagrama de
flujo de datos
físico (inferior)
muestra ciertos
detalles que no se
encuentran en el
diagrama de flujo
de datos lógico
(superior).
Es más fácil usar un modelo lógico al momento de comunicarnos con los usuarios del sistema, ya que se centra
en las actividades de la empresa. En consecuencia, los usuarios están familiarizados con las actividades esencia-
les y con muchos de los requerimientos humanos de información de cada actividad.
Los sistemas que se forman mediante el uso de un diagrama de flujo de datos lógico son a menudo más es-
tables, ya que se basan en eventos de negocios y no en una tecnología o método de implementación específico.
Los diagramas de flujo de datos lógicos representan las características de un sistema que existirían sin importar
cuáles sean los medios físicos de las actividades de negocios. Por ejemplo, las actividades tales como solicitar la
tarjeta de membresía de una tienda de video, revisar un DVD y devolver un DVD se llevarían a cabo sin importar
que la tienda tuviera un sistema automatizado, manual o híbrido.
Cómo desarrollar diagramas de flujo de datos físicos
Una vez que desarrolle el modelo lógico del nuevo sistema, podrá usarlo para crear un diagrama de flujo de datos
físico. Este diagrama muestra cómo se construirá el sistema y por lo general contiene la mayoría de (si no es que
todos) los elementos que se encuentran en la figura 7.10. Así como los diagramas de flujo de datos lógicos tienen
ciertas ventajas, los diagramas de flujo de datos físicos tienen otras:
1. Aclarar qué procesos desempeñan los humanos (manuales) y cuáles son automatizados.
2. Describir los procesos con más detalle que los DFD lógicos.
3. Secuenciar procesos que se tengan que realizar en cierto orden específico.
4. Identificar los almacenes de datos temporales.
5. Especificar los nombres reales de los archivos, tablas de bases de datos y listados impresos.
6. Agregar controles para asegurar que los procesos se realicen en forma apropiada.www.xlibros.com

204 PARTE III • EL PROCESO DE ANÁLISIS
Contenido de los diagramas de flujo de datos físicos
• Procesos manuales
• Procesos para agregar, eliminar, modificar y actualizar registros
• Procesos para introducir y verificar datos
• Procesos de validación para asegurar que se introduzcan los datos con
precisión
• Secuenciar procesos para reorganizar el orden de los registros
• Procesos para producir todas las salidas únicas del sistema
• Almacenes de datos intermedios
• Se utilizan los nombres de archivo reales para guardar datos
• Controles para indicar que se completaron las tareas o condiciones de error
FIGURA 7.10
Los diagramas de flujo de datos
físicos contienen muchos
elementos que no se encuentran en
los diagramas de flujo de datos
lógicos.
Actividad Cliente Artículo Pedido Detalle del pedido
Inicio de sesión del cliente R
Información sobre un artículo R
Selección de un artículo R C C
Pasar a pagar el pedido U U U R
Agregar cuenta C
Agregar artículo C
Cerrar cuenta del cliente D
Quitar artículo obsoleto D
Cambiar demografía del cliente RU
Cambiar pedido del cliente RU RU RU CRUD
Información sobre el pedido R R R R
FIGURA 7.11
Una matriz CRUD para un
escaparate en Internet. Se puede
usar esta herramienta para
representar en dónde ocurren cada
uno de los cuatro procesos (Crear,
Leer, Actualizar y Eliminar
– Create, Read, Update y Delete)
dentro de un sistema.
A menudo los diagramas de flujo de datos físicos son más complejos que los diagramas de flujo de datos lógi-
cos simplemente debido a que hay muchos datos presentes en un sistema. Con frecuencia se utiliza el acrónimo
CRUD para Crear, Leer, Actualizar y Eliminar (Create, Read, Update y Delete), las actividades que deben estar
presentes en un sistema para cada archivo maestro. Una matriz CRUD es una herramienta para representar en
dónde ocurren cada uno de estos procesos en un sistema. La figura 7.11 es una matriz CRUD para un escaparate
en Internet. Cabe mencionar que algunos de los procesos incluyen más de una actividad. Los procesos de entrada
de datos tales como teclear y verificar también forman parte de los diagramas de flujo de datos físicos.
Los diagramas de flujo de datos físicos también tienen almacenes de datos intermedios, a menudo compues-
tos por un archivo de transacciones o una tabla de una base de datos temporal. Con frecuencia los almacenes de
datos intermedios consisten en archivos de transacciones que se utilizan para guardar datos entre procesos. Como
es poco probable que la mayoría de los procesos que requieren acceso a un conjunto dado de información se
ejecuten en el mismo instante, los archivos de transacciones deben contener los datos de un proceso al siguiente.
Podemos encontrar un ejemplo de fácil comprensión sobre este concepto en las experiencias diarias de las com-
pras de abarrotes, la preparación de comidas y la acción de comer. Las actividades son:
1. Seleccionar artículos de los estantes.
2. Pasar a pagar a una caja.
3. Transportar los abarrotes hasta la casa.
4. Preparar una comida.
5. Comer.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 205
Cada una de estas cinco actividades estaría representada por un proceso separado en un diagrama de flujo de datos
físico y cada una ocurre en un momento distinto. Por ejemplo, no sería común transportar los abarrotes a la casa y
comerlos al mismo tiempo. Por lo tanto, se requiere un “almacén de datos de transacciones” para vincular cada
tarea. Al seleccionar elementos, el almacén de datos de transacciones es el carrito de compras. Después del si-
guiente proceso (pasar a pagar), el carrito ya no es necesario. El almacén de datos de transacciones que vincula los
procesos de pasar a pagar y transportar los abarrotes a la casa es la bolsa de compras (¡es más económico que dejar
que usted se lleve el carrito a su casa!). Las bolsas son una manera ineficiente de almacenar los abarrotes una vez que
están en la casa, por lo que se utilizan las alacenas y un refrigerador como almacén de datos de transacciones entre
la actividad de transportar los artículos a la casa y preparar la comida. Por último, un plato, un tazón y un vaso
constituyen el vínculo entre los procesos de preparar y comer los alimentos.
También se puede incluir información de sincronización. Por ejemplo, un DFD físico puede indicar que
se debe ejecutar un programa de edición antes de un programa de actualización. Las actualizaciones se deben
realizar antes de producir un informe de resumen o se debe introducir un pedido en un sitio Web antes de poder
verificar con la institución financiera la cantidad que se va a cargar a una tarjeta de crédito. Cabe mencionar que
debido a tales consideraciones, un diagrama de flujo de datos físico tal vez parezca más lineal que un modelo
lógico.
Para crear el diagrama de flujo de datos físico para un sistema hay que analizar sus salidas y entradas. Al
crear un diagrama de flujo de datos físico, al flujo de datos de entrada que proviene de una entidad externa se
le denomina algunas veces desencadenador, debido a que empieza las actividades de un proceso; al flujo de
datos de salida de una entidad externa se le denomina algunas veces respuesta, ya que se envía como resultado
de alguna actividad. Hay que determinar cuáles campos de datos o elementos hay que teclear. Estos campos se
denominan elementos base y se deben almacenar en un archivo. Los elementos que no se teclean, sino que cons-
tituyen el resultado de un cálculo o una operación lógica, se denominan elementos derivados.
Algunas veces no queda claro cuántos procesos hay que colocar en un diagrama y cuándo se debe crear un
diagrama hijo. Una sugerencia es examinar cada proceso y contar el número de flujos de datos que entran y salen
de él. Si el total es mayor que cuatro, el proceso es un buen candidato para un diagrama hijo. Más adelante en
este capítulo ilustraremos los diagramas de flujo de datos físicos.
MODELADO DE EVENTOS Y DIAGRAMAS DE FLUJO DE DATOS Una metodología práctica para crear diagramas de flujo
de datos físicos es la creación de un fragmento de diagrama de flujo de datos simple para cada evento único del sistema.
Los eventos provocan que el sistema haga algo y actúan como desencadenador para el sistema. Los desen-
cadenadores inician actividades y procesos, los que a su vez utilizan datos o producen salida. Un ejemplo de un
evento es cuando un cliente reserva un vuelo en Web; a medida que se envía cada formulario Web se activan
procesos tales como validar y guardar los datos, o aplicar formato a la siguiente página Web y mostrarla.
Por lo general los eventos se sintetizan en una tabla de respuesta a eventos. En la figura 7.12 se muestra un
ejemplo de una tabla de respuesta a eventos para una empresa con un escaparate en Internet. Un fragmento de
diagrama de flujo de datos se representa mediante una fila en la tabla. Cada fragmento de DFD es un proceso in-
dividual en un diagrama de flujo de datos. Después se combinan todos los fragmentos para formar el Diagrama 0.
Las columnas desencadenador y respuesta se convierten en los flujos de datos de entrada y salida; la actividad se
convierte en el proceso. El analista debe determinar los almacenes de datos requeridos para el proceso mediante
un análisis de los flujos de datos de entrada y salida. En la figura 7.13 se ilustra una parte del diagrama de flujo
de datos para las primeras tres filas de la tabla de respuesta a eventos.
La ventaja de crear diagramas de flujo de datos con base en eventos es que los usuarios están familiari-
zados con los eventos que se llevan a cabo en su área de negocios y saben cómo estos eventos impulsan otras
actividades.
CASOS DE USO Y DIAGRAMAS DE FLUJO DE DATOS En el capítulo 2 presentamos el concepto de un caso de uso.
Utilizamos esta noción de un caso de uso para crear diagramas de flujo de datos. Un caso de uso sintetiza un
evento y tiene un formato similar para procesar las especificaciones (lo cual se describe en el capítulo 9). Cada
caso de uso define una actividad junto con su desencadenador, su entrada y su salida. En la figura 7.14 se ilustra
un caso de uso para el proceso 3, Agregar artículo del cliente.
Este método permite al analista trabajar con los usuarios para comprender la naturaleza de los procesos y
actividades, para después crear un fragmento individual del diagrama de flujo de datos. Al crear casos de uso,
primero hay que hacer un intento por definir los casos de uso sin entrar en detalles. Este paso provee una vista
general del sistema y conduce a la creación del Diagrama 0. Debemos decidir cuáles serán los nombres y proveer
una breve descripción de la actividad. Hay que hacer una lista de las actividades, entradas y salidas de cada uno.
Asegúrese de documentar los pasos utilizados en cada caso de uso. Éstos deben estar en la forma de reglas de
negocios que listen o expliquen las actividades humanas y del sistema que se completaron para cada caso
de uso. Si acaso es posible, liste las actividades en la secuencia en la que normalmente se ejecutarían. Después deter-
mine los datos utilizados en cada paso. Este paso es más fácil si se ha completado un diccionario de datos. Porwww.xlibros.com

206 PARTE III • EL PROCESO DE ANÁLISIS
Evento Actividad Respuesta DestinoOrigen Desencadenador
El cliente
inicia sesión
El cliente explora
los artículos en
el escaparate
Web
El cliente coloca
el artículo en el
carrito de compras
del escaparate
Web
El cliente pasa
a pagar
Obtener pago
del cliente
Enviar un correo
electrónico al cliente
Temporal, por horas ClienteEnviar al cliente un correo
electrónico para confirmar el envío
Cliente Información de tarjeta
de crédito
Verificar el monto de la tarjeta
de crédito con la compañía
de tarjetas de crédito.
Enviar.
Datos de tarjeta
de crédito
Retroalimentación
del cliente
Compañía de
tarjetas
de crédito
Cliente
Cliente Hace clic en el botón
“Pasar a pagar” en la
página Web
Mostrar página Web
del pedido del cliente.
Página Web
de verificación
Almacenar datos en el
Registro detallado del pedido.
Calcular costo de envío
mediante las tablas de envío.
Actualizar el total del cliente.
Actualizar la cantidad del
artículo disponible.
Compra del artículo
(número y cantidad)
Página Web
de artículos
comprados
Número y contraseña
del cliente
Información sobre
artículos
Página Web
de bienvenida
ClienteBuscar registro del
cliente y verificar
contraseña.
Enviar página Web
de bienvenida.
Buscar precio del
artículo y la cantidad
disponible. Enviar página
Web de respuesta de artículo.
Página Web de
respuesta
de artículo
Cliente
Cliente Cliente
Cliente Cliente
FIGURA 7.12
Una tabla de respuesta a eventos para un escaparate en Internet.
último, pida a los usuarios que revisen y sugieran modificaciones de los casos de uso. Es importante que éstos
se escriban en forma clara (en el capítulo 10 encontrará una discusión más detallada sobre el UML, los casos de
uso y los diagramas de casos de uso).
Cómo particionar los diagramas de flujo de datos
El particionamiento es el proceso de examinar un diagrama de flujo de datos y determinar cómo se debe dividir
en colecciones de procedimientos manuales y colecciones de programas de computadora. Hay que analizar cada
proceso para determinar si debe ser manual o automatizado, y agrupar los procedimientos automatizados en una
serie de programas de computadora. Por lo general se dibuja una línea punteada alrededor de un proceso o grupo
de procesos que se deben colocar en un solo programa de computadora.
Hay seis motivos para particionar los diagramas de flujo de datos:
1. Distintos grupos de usuarios ¿Hay varios grupos de usuarios que realizan los procesos, a menudo en
ubicaciones físicas distintas en la empresa? De ser así, hay que particionarlos en distintos programas de
computadora. Un ejemplo es la necesidad de procesar las devoluciones y pagos de los clientes en una tienda
departamental. Para ambos procesos hay que obtener información financiera que se utilice para ajustar las
cuentas de los clientes (restar de la cantidad que debe el cliente), pero distintas personas realizan estos
procesos en ubicaciones distintas. Cada grupo necesita una pantalla distinta para registrar los detalles
específicos de la transacción, ya sea una pantalla de crédito o de pago.
2. Sincronización Hay que examinar la sincronización de los procesos. Si dos procesos se ejecutan en tiempos
distintos, no se pueden agrupar en un programa. Las cuestiones de sincronización también pueden
relacionarse con la cantidad de datos que se presenten en un momento dado en una página Web. Si un sitio
de comercio electrónico tiene páginas Web bastante extensas para ordenar artículos o hacer una reservación de
una aerolínea, tal vez las páginas Web se puedan particionar en programas separados que apliquen formato a
los datos y los presenten.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 207
1
Obtener inicio
de sesión
del cliente
Cliente
Número y contraseña
del cliente
Archivo maestro
del cliente
D1
Página Web de bienvenida
Registro del cliente
2
Explorar
registros de
artículos
Cliente
Información del artículo
Archivo maestro
de artículos
D2Página Web de
respuesta de artículo
Registro de artículo
3
Agregar
artículo del
cliente
Cliente
Artículo comprado
Tablas de envíosD8
Archivo maestro de
artículos
D2
Detalles del pedidoD7
Archivo maestro del
cliente
D1
Página Web de
artículos comprados
Registro de artículo
Tarifas de envío
Detalles del pedido
Registro de cliente
FIGURA 7.13
Diagramas de flujo de datos para
las primeras tres filas de la tabla
de respuesta a eventos del
escaparate en Internet.
3. Tareas similares Si dos procesos realizan tareas similares, se pueden agrupar en un programa de
computadora.
4. Eficiencia Se pueden combinar varios procesos en un programa para un procesamiento eficiente. Por
ejemplo, si varios informes necesitan usar los mismos archivos de entrada extensos, al producirlos en
conjunto podríamos ahorrar una cantidad considerable de tiempo de ejecución de la computadora.
5. Consistencia de los datos Los procesos se pueden combinar en un programa para lograr la consistencia de
los datos. Por ejemplo, una compañía de tarjetas de crédito puede tomar una “instantánea” y producir una
variedad de informes al mismo tiempo, de manera que las cifras sean consistentes.
6. Seguridad Los procesos se pueden particionar en distintos programas por cuestiones de seguridad. Se puede
colocar una línea punteada alrededor de las páginas Web que estén en un servidor seguro para separarlas
de las páginas Web en un servidor que no esté seguro. Por lo general, una página Web que se utiliza para
obtener la identificación y contraseña del usuario se particiona para separarla de las páginas de introducción
de pedidos o de otras páginas con actividades de negocios.
EJEMPLO DE UN DIAGRAMA DE FLUJO DE DATOS
El siguiente ejemplo ilustra el desarrollo de un diagrama de flujo de datos mediante un análisis selectivo de cada
uno de los componentes que exploramos anteriormente en el capítulo. Este ejemplo conocido como “División de
catálogos de World’s Trend”, se utilizará también para ilustrar los conceptos que veremos en los capítulos 8 y 9.
Desarrollar la lista de actividades de negocios
En la figura 7.15 encontrará una lista de actividades de negocios para World’s Trend; para desarrollarla podría-
mos utilizar la información que se obtiene al interactuar con las personas en las entrevistas, por medio de la
investigación y a través de la observación. Podemos usar esta lista para identificar a las entidades externas como
CLIENTE, CONTABILIDAD y ALMACÉN, así como los flujos de datos tales como INFORME DE CUEN-
TAS POR COBRAR y ESTADO DE CUENTA DE FACTURACIÓN DE CLIENTE. Más adelante (cuandowww.xlibros.com

208 PARTE III • EL PROCESO DE ANÁLISIS
1. Buscar el registro del artículo mediante el número del mismo. Si no se
encontró el artículo, colocar un mensaje en la página Web de artículos
comprados.
2. Almacenar los datos del artículo en el Registro de detalles del pedido.
3. Usar el número de cliente para buscar el registro del cliente.
4. Calcular el Costo de envío mediante el uso de tablas de envíos. Usar el Peso
del artículo del Registro del artículo y el Código postal del Registro del cliente
para buscar el Costo de envío en las Tablas de envíos.
5. Modificar el Total del cliente mediante el uso de la Cantidad comprada y el
Precio del artículo. Agregar el Costo de envío. Actualizar el Registro del cliente.
6. Modificar la Cantidad del artículo disponible y actualizar el Registro del artículo.
Pasos realizados
Información para los pasos
Nombre de entrada
Tipo de desencadenador: Externo Temporal
Desencadenador: El cliente coloca un artículo que desea pedir en el carrito de compras.
Descripción: Agrega el artículo para el pedido de un cliente por Internet.
Nombre del caso de uso: Agregar artículo del cliente ID del proceso: 3
Nombre de salidaOrigen Destino
Artículo comprado
(número y
cantidad)
Página Web de
confirmación de
artículos
comprados
Cliente Cliente
Número de artículo,
registro de artículo
Número de cliente,
registro del cliente
Registro de detalles
del pedido
Código postal, Peso del
artículo, Tabla de envíos
Cantidad ordenada,
Registro del artículo
Registro de artículo,
Cantidad comprada,
Costo de envío, Registro
del cliente
FIGURA 7.14
Un formulario de
caso de uso para el
escaparate en Internet
describe la actividad
Agregar artículo del
cliente junto con sus
desencadenadores,
entrada y salida.
desarrollemos el diagrama de nivel 0 y los diagramas hijos) podremos usar la lista para definir los procesos,
flujos de datos y almacenes de datos.
Crear un diagrama de flujo de datos a nivel de contexto
Una vez que se desarrolla esta lista de actividades hay que crear un diagrama de flujo de datos a nivel de con-
texto, como el que se muestra en la figura 7.16. Este diagrama muestra el SISTEMA DE PROCESAMIENTO
DE PEDIDOS en la parte media (en el diagrama a nivel de contexto no se describen los procesos con detalle)www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 209
World’s Trend es un proveedor de pedidos por correo de ropa de moda y alta calidad. Los
clientes hacen sus pedidos por teléfono, envían un formulario de pedido que se incluye con
cada catálogo o lo hacen a través del sitio Web.
Resumen de las actividades de negocios
1. Cuando entran los pedidos de los clientes, se actualiza tanto el archivo maestro de artículos
como el archivo maestro de clientes. Si un artículo no está en existencia, se notifica al
departamento de control de inventario.
Si el pedido proviene de un nuevo cliente, se crea un registro en el archivo maestro de clientes.
Se producen listas de selección de pedido para el pedido del cliente y se envían al almacén.
Se prepara un estado de cuenta del envío.
El proceso de enviar el pedido de un cliente implica obtener los artículos del almacén y
cotejar el estado de cuenta del envío del cliente, obtener la dirección correcta del cliente
y enviar todo al cliente.
Se genera el estado de cuenta del cliente y se envía un estado de cuenta de facturación
al cliente una vez al mes.
Se envía un informe de cuentas por cobrar al departamento de contabilidad.
2.
3.
4.
5.
6.
7.
1000 International Lane
Cornwall, CT 06050
W orld’s Trend
FIGURA 7.15
Un resumen de las actividades
de negocios para la División de
catálogos de World’s Trend.
Sistema de
procesamiento
de pedidos
0
Artículo en pedido pendiente
Pedido del cliente
Información del nuevo cliente
Número o descripción del artículo
y
Pedido enviado
Estado de cuenta de facturación del cliente
Información de artículo
Informe de cuentas por cobrar
Lista de selección de pedido
Artículos del pedido
Cliente
Departamento
de control
de inventario
Cliente
Departamento
de
contabilidad
Almacén
FIGURA 7.16
Un diagrama de flujo de
datos a nivel de contexto
para el sistema de
procesamiento de pedidos
en World’s Trend.www.xlibros.com

210 PARTE III • EL PROCESO DE ANÁLISIS
y cinco entidades externas (las dos entidades separadas que se llaman CLIENTE son en realidad una misma).
También se muestran los flujos de datos que salen y entran en las entidades externas (por ejemplo, PEDIDO
DEL CLIENTE y LISTA DE SELECCIÓN DE PEDIDO).
Dibujo del Diagrama 0
Ahora hay que regresar a la lista de actividades y hacer una nueva lista de todos los procesos y almacenes de da-
tos que podamos encontrar. Podemos agregar más después, pero hay que empezar a hacer la lista en este punto.
Si cree tener suficiente información, dibuje un diagrama de nivel 0 como el de la figura 7.17. Asigne a este
diagrama el nombre Diagrama 0 y mantenga los procesos en un nivel general, para no complicar el diagrama de
Agregar
pedido
del cliente
1
D2 Archivo maestro
de artículos
Registro
de artículo
Pedido del cliente
y
Artículo en pedido pendiente
Agregar
registro de
cliente
2
Información
del nuevo
cliente
Registro
de cliente
Registro
de cliente
Producir
cuentas por
cobrar
7
Informe de
cuentas por
cobrar
Crear estado
de cuenta
del cliente
6
Estado de
cuenta de
envío del
cliente
4
Pedido
pendiente
Preparar estado
de cuenta de
envío
Producir
listas de
selección
3
Enviar
pedido del
cliente
5
Nombre y dirección
del cliente
Registro
del cliente
Registro
de cliente
Pedido
pendiente
Pedido
pendiente
Pedido
pendiente
Pedido
pendiente
Lista de
selección del pedido
Artículos que cumplen
con el pedido
Pedido enviado
Estado de cuenta de
facturación del cliente
Almacén
Cliente
Cliente
Departamento
de control
de inventarios
D1 Archivo maestro
de clientes
Departamento
de
contabilidad
8
Información
del artículo
Número o
descripción
del artículo
D1 Archivo maestro
del cliente
Consultar
información
de artículo
Cliente
FIGURA 7.17
Diagrama 0 del
sistema de
procesamiento
de pedidos para la
División de
catálogos
de World’s Trend.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 211
más (después podrá agregar más detalles). Cuando termine de dibujar los siete procesos, dibuje flujos de datos
entre ellos y hacia las entidades externas (las mismas entidades externas que se muestran en el diagrama a nivel
de contexto). Si cree que debe haber almacenes de datos como ARCHIVO MAESTRO DE ARTÍCULOS o AR-
CHIVO MAESTRO DE CLIENTES, dibújelos y conéctelos a los procesos mediante el uso de flujos de datos.
Ahora tómese el tiempo de enumerar los procesos y almacenes de datos. Ponga atención especial al momento de
asignar etiquetas significativas. Compruebe los errores y corríjalos antes de continuar.
Crear un diagrama hijo
En este punto trate de dibujar un diagrama hijo (algunas veces también se le conoce como diagrama de nivel 1),
como el de la figura 7.18. Los procesos en los diagramas hijos están más detallados, ya que ilustran la lógica re-
querida para producir la salida. Enumere sus diagramas hijos como Diagrama 1, Diagrama 2 y así en lo sucesivo,
de acuerdo con el número que haya asignado a cada proceso en el diagrama de nivel 0.
Al dibujar un diagrama hijo, haga primero una lista de subprocesos. Un proceso tal como AGREGAR PE-
DIDO DEL CLIENTE puede tener subprocesos (en este caso hay siete). Conecte estos subprocesos entre sí y
Registro del cliente
Validar
cuenta del
cliente
1.1
Error: no se
encontró el cliente
Pedido del
cliente
D1 Archivo maestro
de clientes
Registro
del cliente
Información válida del cliente
Información válida del cliente
Actualizar
registro
del cliente
1.6
Crear
pedido
pendiente
1.7 Pedido
pendiente
Pedido del
cliente
Totales
del pedido
Totales
del pedido
Calcular
totales del
pedido
1.5
Precio y peso
del artículo
D4 Tabla de envíos
y manejo
D2 Archivo maestro
de artículos
Costos de envío
Determinar
cantidad
disponible
1.3
Artículo en
pedido pendiente
Validar
artículo del
pedido
1.2
Error: no se
encontró el
artículo
Pedido del
cliente Artículo válido
Cantidad del artículo
disponible
Artículo
disponible
Artículo
disponible
Artículo
disponible
Actualizar
cantidad de
artículo
1.4
Registro
de artículo
D2 Archivo maestro
de artículos
FIGURA 7.18
Diagrama 1 del sistema de
procesamiento de pedidos para la
División de catálogos de World’s
Trend.www.xlibros.com

212 PARTE III • EL PROCESO DE ANÁLISIS
también con los almacenes de datos cuando sea apropiado. Los subprocesos no tienen que estar conectados a en-
tidades externas, ya que siempre podemos hacer referencia al diagrama de flujo de datos padre (o de nivel 0) para
identificar estas entidades. Asigne etiquetas a los subprocesos como 1.1, 1.2, 1.3, etcétera. Tómese el tiempo de
revisar errores y asegurarse de que las etiquetas tengan sentido.
Crear un diagrama de flujo de datos físico a partir del DFD lógico
Si desea ir más allá del modelo lógico y dibujar también un modelo físico, vea la figura 7.19, un ejemplo de un
diagrama hijo de flujo de datos físico del proceso 3, LISTAS DE SELECCIÓN DE PEDIDO. Los DFD físicos
dan la oportunidad de identificar procesos para escanear los códigos de barras, mostrar pantallas, localizar regis-
Leer
registro de
artículo
3.1
Ubicación de recipiente
y sección del artículo
Información de
artículo del pedido
D2 Archivo maestro
de artículos
Registro de pedido Crear
registro de
artículo del
pedido
3.2 Registro de artículo
del pedido
Registro de
artículo del
pedido
D6 Archivo de artículos
del pedido
Obtener
registro
del cliente
3.4
Registro
del cliente
Nombre del cliente
D1 Archivo maestro
de clientes
Nombre, dirección
y teléfono del cliente
Aplicar
formato a
líneas del
cliente
3.5
Línea del cliente
Registro del
artículo
ordenado
Aplicar
formato a
líneas del
artículo
3.6
Línea de artículo
del pedidoImprimir
lista de
selección del
pedido
3.7
Lista de
selección del
pedido
Registro del
artículo
ordenado
D7 Archivo de
artículos ordenados
Ordenar
artículo por
ubicación
dentro del
almacén
3.3
FIGURA 7.19
Un diagrama hijo de flujo de
datos físico para la División
de catálogos de World’s Trend.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 213
tros, crear y actualizar archivos. La secuencia de actividades es importante en los DFD físicos, ya que se hace
énfasis en la forma en que trabajará el sistema y en qué orden ocurrirán los eventos.
Al etiquetar un modelo físico debe tener cuidado en describir el proceso con mucho detalle. Por ejemplo, el
subproceso 3.3 en un modelo lógico podría ser simplemente ORDENAR ARTÍCULO, pero en el modelo físico
sería mejor etiquetarlo como ORDENAR ARTÍCULO POR UBICACIÓN DENTRO DEL CLIENTE. Al escribir
una etiqueta para un almacén de datos, haga referencia al archivo o base de datos real, como ARCHIVO MAES-
TRO DE CLIENTES o ARCHIVO DE ARTÍCULOS ORDENADOS. Al describir los flujos de datos describa
el formulario, informe o pantalla real. Por ejemplo, al imprimir una lista de selección de pedido puede asignar al
flujo de datos el nombre LISTA DE SELECCIÓN DE PEDIDO.
Cómo particionar el DFD físico
Por último hay que tomar el diagrama de flujo de datos físico y sugerir su particionamiento por medio de la se-
paración o combinación de los procesos. Como dijimos antes, hay muchas razones para particionar: identificar
distintos procesos para distintos grupos de usuarios, separar procesos que se necesitan realizar en distintos mo-
mentos, agrupar tareas similares, agrupar procesos para mejorar la eficiencia, combinar procesos para lograr una
consistencia o separarlos por cuestión de seguridad. La figura 7.20 muestra que el particionamiento es útil en el
caso de la División de catálogos de World’s Trend. Primero sería conveniente agrupar los procesos 1 y 2, ya que
tendría sentido agregar nuevos clientes al mismo tiempo que colocaran su primer pedido. Después podríamos
colocar los procesos 3 y 4 en dos particiones separadas, ya que cada uno de estos procesos se debe realizar en un
momento distinto y, por ende, no se pueden agrupar en un solo programa.
El proceso de desarrollar un diagrama de flujo de datos ahora está completo de arriba hacia abajo; primero
dibujamos un diagrama de flujo de datos físico para acompañar al diagrama de flujo de datos lógico y después
agrupamos o separamos los procesos. En los capítulos 8 y 9 volveremos a usar el ejemplo de World’s Trend.
PARTICIONAMIENTO DE SITIOS WEB
El particionamiento es un principio muy útil al diseñar un sitio Web. Los diseñadores de sitios Web que utilizan
formularios para recopilar datos pueden encontrar más apropiado dividir un sitio Web en una serie de páginas
Web, lo cual mejorará la forma en que los humanos utilizan el sitio, aumentará la velocidad de procesamiento y
facilitará el mantenimiento del mismo. Cada vez que haya que obtener datos de un almacén de datos o socio ex-
terno, es conveniente que el diseñador Web considere la creación de un formulario Web único y un proceso DFD
para validar y procesar los datos.
El desarrollador Web también puede usar Ajax para enviar una petición al servidor y recibir una pequeña
cantidad de datos o un documento XML de vuelta en la misma página. Se puede utilizar Ajax para evitar la
necesidad de crear demasiadas páginas pequeñas que contengan sólo unos cuantos elementos adicionales o
modificados en el formulario Web. Sin embargo, el analista debe crear varias páginas Web cuando sea nece-
sario. Por ejemplo, consideremos el caso en el que hay que obtener una gran cantidad de datos del servidor,
como una lista de todos los vuelos que concuerden con los aeropuertos de salida y de destino para ciertos
días de viaje. Al acceder a distintas tablas de la misma base de datos, se pueden obtener datos que contengan
campos de distintas tablas y se pasen a un proceso. Pero si hay varias bases de datos involucradas, tal vez el
analista decida usar páginas Web separadas. Al requerir la entrada del usuario, el analista puede usar páginas
Web separadas o Ajax para facilitar un cambio en una lista desplegable o modificar una pequeña cantidad de
información.
Podemos ver un buen ejemplo de particionamiento en el desarrollo de un sitio de reservaciones de viajes ba-
sado en Web. Para simplificar sólo analizaremos la parte correspondiente a la reservación de la aerolínea del sitio
Web, la cual se muestra en el diagrama de flujo de datos de la figura 7.21. Cabe mencionar que el diseñador Web
optó por crear varios procesos y particiones únicas para hacer una reservación de un vuelo. El proceso 1 recibe
y valida las fechas y aeropuertos introducidos por el cliente (o el agente de viajes que esté ayudando al cliente).
Los datos de la selección se utilizan para obtener detalles de los vuelos y crear un almacén de datos de transac-
ciones de los detalles sobre los vuelos que coincidan con la solicitud.
Es conveniente particionar el proceso de buscar la información de los vuelos como un proceso separado, ya
que hay que buscar en un almacén de datos y los detalles de los vuelos se utilizarán para mostrar una serie de
páginas Web sucesivas con vuelos que coincidan. Después, una vez que el cliente seleccione un vuelo, hay que
enviar la información a una aerolínea seleccionada. Es importante tener el archivo de transacciones de DETA-
LLES DE VUELOS disponible para mostrar cada página Web de nuevos vuelos, ya que para volver a realizar el
proceso de búsqueda tal vez se requiera una cantidad de tiempo que sea inaceptable para un humano que trate de
completar una transacción.www.xlibros.com

214 PARTE III • EL PROCESO DE ANÁLISIS
La selección de vuelos disponibles (proceso 2) utiliza una base de datos interna, pero esta base de datos no
tiene información sobre la disponibilidad de asientos, ya que las aerolíneas reciben reservaciones de muchas or-
ganizaciones de servicios de viajes. Esto significa que debe haber un proceso separado y un pequeño programa
particionados para determinar si los asientos están disponibles y para reservar asientos específicos.
Como hay muchos procesos de entrada de usuario, se diseñan formularios para manejar todas las peticiones
relacionadas. Tener formularios separados implica que los formularios serán menos complejos, por lo que los
usuarios los encontrarán más atractivos y fáciles de llenar. Este diseño cumple con los criterios de capacidad de
uso y utilidad importantes al diseñar sitios Web para la interacción humano-computadora. También significa que
el procesamiento se realizará con más rapidez, pues una vez que seleccione el vuelo, en el siguiente paso rela-
cionado con la selección de asientos, el usuario ya no tendrá que introducir —ni ver— los detalles del vuelo otra
vez. La mayoría de los sitios Web de las aerolíneas utilizan ahora ventanas desplegables en las que los clientes
apuntan su selección de asientos.
Agregar
pedido del
cliente
1
Cliente
D1 Archivo maestro
de clientes
Registro
del cliente
Pedido del
cliente D3 Archivo de pedidos
D2 Archivo maestro
de artículos
Registro
del artículo
Departamento
de control de
inventario
Agregar
registro del
cliente
2 Nuevo
registro
del cliente Preparar
estado de
cuenta
de envío
4
Registro
del pedido
D2 Archivo maestro
de artículos
Producir
listas de
selección
3
Registro
del artículo
Nombre y
dirección del
cliente
D1 Archivo maestro
de clientes
Almacén
Enviar
pedido del
cliente
5 Artículos del
pedido
Estado de cuenta
de envío del
cliente
Nombre y dirección del cliente
Lista de
selección
de pedido
Registro
del pedidoPendiente
Información
del nuevo
cliente
Registro
del cliente
Registro
del artículo
Registro de artículos pendientes
Detalles del envío
Los procesos número 3 y 4
son procesos en lote pero se
deben particionar en programas
separados, ya que se realizan
en distintos momentos.
El proceso 3 es un proceso
por lotes, ya que tiene una
salida de computadora, la
Lista de selección de pedido
y una entrada de computadora
(los tres archivos).Para indicar el particionamiento
hay que rodear los procesos
incluidos en un solo programa
con una línea punteada. El
cliente se agregaría al momento
de colocar un pedido.
Cliente
FIGURA 7.20
Particionamiento del diagrama de
flujo de datos (se muestra parte
del Diagrama 0).www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 215
Cliente
Boleto-e
Confirmación por
correo electrónico
Fechas y
códigos de
aeropuertos
Fechas y
aeropuertos
Precio y
disponibilidad de
los vuelos
Selección
de vuelos
Detalles de vuelos
disponibles
Vuelo seleccionado
Rechazo del crédito
Información
del cliente
Selección de asientos
Detalles de
vuelos
disponibles
Pantalla de
vuelos
disponibles
Información de vuelo y asiento seleccionados
D1 Vuelo
D3 Archivo maestro
de clientes
Seleccionar
asientos
disponibles
4
D5 Reservación de vuelo
Información de
tarjeta de crédito
Estado del crédito
Confirmación
del crédito
Información de
tarjeta de crédito
Compra
del vuelo
Información de vuelos
Información
de vuelos
Reservación de vuelos
Registro del cliente
Seleccionar
vuelos
3
Reservar
vuelo
5
Seleccionar
días de vuelo
y aeropuertos
1
Mostrar
vuelos
disponibles
2
Sistema de
tarjetas de
crédito
8
Producir
boleto-e del
cliente
Hacer cargo a
la tarjeta de
crédito del
cliente
6
Actualizar
vuelos de
aerolínea
7
Aerolínea
Aerolínea
D2 Detalles de vuelos
Cliente
FIGURA 7.21
El particionamiento es
importante para los sistemas
basados en Web, como lo
demuestra este diagrama de flujo
de datos físico de un sistema de
compra de boletos en línea.
Otro de los motivos del particionamiento es para mantener la transacción segura. Una vez seleccionado el
asiento, el cliente debe confirmar la reservación y suministrar la información de su tarjeta de crédito. Para ello se
utiliza una conexión segura, a través de la cual la compañía de tarjetas de crédito se involucra en el proceso de
validación del monto de la compra. Para la conexión segura hay que usar un proceso separado. Una vez confir-
mada la tarjeta de crédito es necesario incluir dos procesos adicionales: uno para dar formato a la confirmación
y enviarla por correo electrónico junto con un boleto-e para el cliente, y otro para enviar la notificación de la
compra del vuelo a la aerolínea.www.xlibros.com

216 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U L T O R Í A 7 . 1
No hay negocio como el negocio de los flujos
Suena el teléfono en la empresa Merman’s Costume Rentals;
Annie Oaklea, jefa de inventario de vestuarios, toma la llamada; para
responder a la consulta dice: “Permítame ver mis tarjetas de inven-
tario. Lo siento: en inventario tenemos sólo dos trajes de oso macho
con expresiones extra gruñonas. Hemos tenido mucha demanda de
osos. ¿Para cuándo los necesita? Tal vez regresen uno. No, lo siento,
no puedo. ¿Le gustaría que le enviara estos dos de todas maneras?
¿El nombre de su establecimiento? ¿Compañía de teatro de Man-
hattan? ¿Sucursal de Londres? Correcto. ¡Maravillosa compañía de
teatro! En la tarjeta de su cuenta puedo ver que han rentado vestuario
con nosotros antes. ¿Cuánto tiempo los necesitará?”.
La figura 7.C1 es un diagrama de flujo de datos que establece
la etapa para procesar las rentas de vestuarios de Merman’s. Mues-
tra rentas tales como la que Annie está preparando para la Compa-
ñía de teatro de Manhattan.
Después de conversar por unos instantes sobre la política de
la tienda con respecto a las alteraciones, Annie concluye su con-
versación diciendo: “Tienen mucha suerte de que los trajes de oso
estén disponibles con tan poca anticipación. Tengo otra compañía
que los reservó para la primera semana de julio. Voy a prepararle
sus trajes y nuestro mensajero se los llevará directamente. Una
última cosa: como siempre, la devolución oportuna de los trajes
nos ahorrará enormes problemas a todos”.
La empresa de renta de vestuarios de Merman se encuentra
en el famoso distrito de teatros de la parte oeste de Londres.
Cuando una compañía de producción de teatro o televisión
carece de los recursos (ya sea tiempo o experiencia) para cons-
truir un vestuario en su propio taller, alguien grita: “¡Llamen a
Merman’s!” y se procede a rentar lo necesario sin mucho es-
cándalo.
y
Aprobación
de crédito
Información de
disponibilidad
Pedido Pedido válido
Dirección
del cliente
Detalles
del pedido
Detalles del envío
Información
de envío
Factura
de envíoProcesar
facturas de
envío
3
Recopilar
envío de
vestuarios
de renta
2
Editar
pedido
1
Clientes
Clientes
D1 Vestuarios en
el inventario
D2 Información
del cliente
D3 Pedido del
cliente
FIGURA 7.C1
Un diagrama de flujo de datos para la empresa Merman’s Costume Rentals.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 217
Hay que particionar todo el procedimiento en una serie de procesos relacionados, cada uno de los cuales
debe tener su correspondiente página Web o interactuar con un sistema externo. Cada vez que se utiliza un nuevo
almacén de datos para obtener datos adicionales, hay que incluir un proceso para dar formato a los datos u obte-
nerlos. Cada vez que se involucra una empresa o sistema externo, hay que particionar un proceso en un programa
separado. La tarea de revisar procesos o formularios no es primordial. El tamaño pequeño de los programas faci-
lita su modificación. De esta forma el sitio Web será seguro, eficiente y más fácil de mantener.
COMUNICACIÓN MEDIANTE EL USO DE DIAGRAMAS DE FLUJO DE DATOS
Los diagramas de flujo de datos son útiles en todo el proceso de análisis y diseño. Hay que utilizar diagramas
de flujo de datos originales sin expandir durante las primeras etapas del proceso, al averiguar los requeri-
mientos de información. En esta etapa, los diagramas nos pueden ayudar a proveer las generalidades sobre el
movimiento de los datos a través del sistema, con lo cual obtendremos una perspectiva visual que no se puede
obtener a través de los datos de las narrativas.
Un analista de sistemas podría ser bastante competente al realizar un bosquejo de toda la lógica del flujo continuo
de datos para los diagramas de flujo de datos, pero para que los diagramas sean verdaderamente comunicativos para
los usuarios y otros miembros del equipo del proyecto, también se requieren etiquetas significativas para todos los
componentes de datos. Las etiquetas no deben ser genéricas debido a que no podrán indicar lo suficiente sobre la si-
tuación existente en un momento dado. Todos los modelos de sistemas en general poseen la configuración de entrada,
proceso y salida, por lo que las etiquetas para un diagrama de flujo de datos necesitan ser más específicas que eso.
Por último debemos recordar que los diagramas de flujo de datos se utilizan para documentar el sistema.
Hay que suponer que los diagramas de flujo de datos existirán mucho más tiempo que las personas que los dibu-
jaron, lo que en definitiva siempre es verdad si un consultor externo es el que los dibuja. Se pueden utilizar los
diagramas de flujo de datos para documentar niveles altos o bajos de análisis y para ayudar a confirmar la lógica
detrás de los flujos de datos de las organizaciones.
La tienda (que se puede visualizar mejor como un almacén)
abarca tres pisos llenos de estantes de vestuarios que contienen
miles de disfraces colgados en conjunto por periodo histórico, para
después agruparlos con base en el género y por último con base en
la talla 1. La mayoría de las compañías de teatro pueden ubicar con
precisión lo que necesitan por medio de la hábil ayuda de Annie.
Ahora cree a la medida la porción de devolución de renta del
diagrama de flujo de datos anterior. Recuerde que es imprescindible
que las entregas sean oportunas para el óptimo funcionamiento de
Merman’s.
1 Se dice que la empresa Western Costume Company en Hollywood, California,
tiene más de 1 millón de vestuarios con un valor aproximado de $40 millones.
RESUMEN
Para comprender mejor el movimiento lógico de los datos a
través de una empresa, el analista de sistemas dibuja diagramas
de flujo de datos (DFD). Estos diagramas son herramientas es-
tructuradas de análisis y diseño, las cuales permiten al analista
comprender el sistema y los subsistemas en forma visual, como
un conjunto de flujos de datos interrelacionados.
Las representaciones gráficas del almacenamiento y la trans-
formación del movimiento de los datos se dibujan mediante el
uso de cuatro símbolos: un rectángulo redondeado para describir
el procesamiento o las transformaciones de los datos, un cua-
drado doble para mostrar una entidad de datos externa (origen o
receptor de los datos), una flecha para describir el flujo de datos
y un rectángulo con un extremo abierto para mostrar un almacén
de datos.
El analista de sistemas extrae los procesos, orígenes, alma-
cenes y flujos de datos de las narrativas o historias de la orga-
nización que contaron los usuarios o que revelaron los datos,
y utiliza una metodología arriba-abajo para dibujar primero un
diagrama de flujo de datos a nivel de contexto del sistema con
una vista más amplia. Después se dibuja un diagrama de flujo
de datos lógico de nivel 0. Se muestran los procesos y se agre-
gan los almacenes de datos. A continuación, el analista crea un
diagrama hijo para cada uno de los procesos en el Diagrama 0.
Las entradas y salidas permanecen constantes, pero los almace-
nes de datos y los orígenes cambian. Al expandir el diagrama de
flujo de datos original, el analista de sistemas se puede concen-
trar en descripciones más detalladas del movimiento de datos en
el sistema. Después, el analista desarrolla un diagrama de flujo
de datos físico a partir del diagrama de flujo de datos lógico y lo
particiona para facilitar la programación. Se analiza cada proceso
para determinar si debe ser manual o automatizado.
Las seis consideraciones para particionar diagramas de
flujo de datos son: 1) que distintos grupos de usuarios realicen
los procesos, 2) que los procesos se ejecuten en los mismos
tiempos, 3) que los procesos realicen tareas similares, 4) que se
puedan combinar procesos en lote para un procesamiento efi-
ciente, 5) que se puedan combinar los procesos en un programa
para lograr la consistencia de los datos, o 6) que los procesos
se puedan particionar en distintos programas por cuestiones de
seguridad.www.xlibros.com

218 PARTE III • EL PROCESO DE ANÁLISIS
EXPERIENCIA DE HYPERCASE® 7
“U sted aborda de una manera muy interesante los pro-
blemas que tenemos aquí en MRE. Lo he visto hacer bosque-
jos de diagramas de nuestra operación casi desde el día en
que entró. De verdad que me estoy acostumbrando a verlo
hacer garabatos. ¿Cómo se llaman ésos? Ah sí, diagramas a
nivel de contexto. ¿Y redes de flujos? Oh, no. Diagramas de
flujo de datos. Sí, ¿verdad?”.
Preguntas de HYPERCASE
1. Busque los diagramas de flujo de datos que ya están dibujados en
MRE. Haga una lista de los que encuentre y agregue una columna
para mostrar dónde los encontró dentro de la organización.
2. Dibuje un diagrama a nivel de contexto para modelar el proceso
de Desarrollo del proyecto de la unidad de capacitación (Training
Unit Project Development), uno que se base en las entrevistas
con el personal relevante de la Unidad de capacitación. Después
dibuje un diagrama de nivel 0 para detallar el proceso.
FIGURA 7.EH1
En HyperCase podemos hacer clic en los elementos de un diagrama de flujo de datos.
PALABRAS CLAVE Y FRASES
Ajax
almacén de datos
almacén de datos de transacciones
almacén de datos físico
balanceo vertical
caso de uso
desencadenador de evento
diagrama de flujo de datos
diagrama de flujo de datos a nivel de contexto
diagrama de nivel 0
diagrama hijo
elemento base
elementos derivados
entidad externa (origen o destino)
expandir
flujo de datos de interfaz
fragmento de diagrama de flujo de datos
funcionalmente primitivo
lenguaje unificado de modelado (UML)
metodología arriba-abajo
modelado de eventos
modelo físico
modelo lógico
particionamientowww.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 219
PREGUNTAS DE REPASO
1. ¿Cuál es uno de los principales métodos disponibles que el analista puede usar para analizar sistemas orientados a datos?
2. ¿Cuáles son las cuatro ventajas de usar una metodología de flujo de datos en vez de las explicaciones narrativas del
movimiento de los datos?
3. ¿Cuáles son los cuatro elementos de datos que se pueden simbolizar en los diagramas de flujo de datos?
4. ¿Qué es un diagrama de flujo de datos a nivel de contexto? Compárelo con un DFD de nivel 0.
5. Defina la metodología arriba-abajo y su relación con la acción de dibujar diagramas de flujo de datos.
6. Describa qué significa “expandir” diagramas de flujo de datos.
7. ¿Cuáles son las concesiones implicadas en el proceso de decidir cómo se deben expandir los flujos continuos de datos?
8. ¿Por qué es tan importante etiquetar los diagramas de flujo de datos? ¿Qué pueden lograr las etiquetas efectivas en los
diagramas de flujo de datos para aquellos que no están familiarizados con el sistema?
9. ¿Cuál es la diferencia entre los diagramas de flujo de datos físico y lógico?
10. Mencione tres razones para crear un diagrama de flujo de datos lógico.
11. Mencione cinco características que se incluyen en un diagrama de flujo de datos físico y que no se encuentran en un
diagrama de flujo de datos lógico.
12. ¿Cuándo se requieren los archivos de transacciones en el diseño del sistema?
13. ¿Cómo se puede utilizar una tabla de eventos para crear un diagrama de flujo de datos?
14. Mencione las principales secciones de un caso de uso.
15. ¿Cómo se puede utilizar un caso de uso para crear un diagrama de flujo de datos?
16. ¿Qué es el particionamiento y cómo se utiliza?
17. ¿Cómo puede determinar un analista cuándo se requiere una interfaz?
18. Mencione tres formas de determinar el particionamiento en un diagrama de flujo de datos.
19. Mencione tres formas de usar los diagramas de flujo de datos completos.
PROBLEMAS
1. Hasta este punto parece tener una excelente relación de comunicación con Kevin Cahoon, el propietario de una empresa
de fabricación de instrumentos musicales. Cuando usted le mostró un conjunto de diagramas de flujo de datos que
dibujó, él no pudo ver cómo estaba descrito en los diagramas el sistema representado.
a. En un párrafo escriba en términos generales cómo podría explicar un diagrama de flujo de datos a un usuario.
Asegúrese de incluir una lista de símbolos y su significado.
b. Se requiere cierto esfuerzo para educar a los usuarios sobre los diagramas de flujo de datos. ¿Vale la pena
compartirlos con los usuarios? ¿Por qué sí o por qué no? Defienda su respuesta en un párrafo.
c. Compare los diagramas de flujo de datos con los casos de uso y los escenarios de los casos de uso. ¿Qué
muestran los diagramas de flujo de datos que los diagramas de casos de uso tienen muchas dificultades para
explicar?
2. Su proyecto más reciente es combinar dos sistemas utilizados por la empresa Producers Financial. El sistema
de aplicación de préstamos de Angie Schworer es bastante reciente, pero no tiene documentación. El sistema de
administración de préstamos de Scott Wittman es más antiguo, requiere de una buena revisión y los registros están
codificados de manera independiente al otro sistema. El sistema de aplicación de préstamos acepta solicitudes, las
procesa y recomienda los préstamos que se pueden aprobar. El sistema de administración de préstamos recibe los
préstamos que se aprobaron y les da seguimiento hasta su disposición final (pagado, vendido o moroso). Dibuje un
diagrama de contexto y un diagrama de flujo de datos de nivel 1 que muestre cómo se vería un sistema combinado
idealizado.
3. Una experiencia común que comparten todos los estudiantes en todos los colegios y universidades es la de inscribirse en
un curso universitario.
a. Dibuje un diagrama de flujo de datos de nivel 1 del movimiento de datos para inscribirse en un curso universitario.
Use una sola hoja y etiquete cada elemento de datos con claridad.
b. Expanda uno de los procesos en su diagrama de flujo de datos original en subprocesos; agregue flujos y almacenes
de datos.
c. Haga una lista de las partes del proceso de inscripción que estén “ocultas” para el observador externo y sobre las
cuales haya tenido que hacer suposiciones para completar un diagrama de segundo nivel.
4. La figura 7.EJ1 es un diagrama de flujo de datos de nivel 1 del movimiento de datos en una agencia de paseos por las
cataratas del Niágara llamada Marilyn’s Tours. Léalo y revise cualquier inconsistencia.
a. Haga una lista y enumere los errores que haya encontrado en el diagrama.
b. Vuelva a dibujar y etiquetar el diagrama de flujo de datos de Marilyn’s para corregirlo. Asegúrese de que su nuevo
diagrama emplee los símbolos en forma apropiada para reducir las repeticiones y duplicaciones en donde sea
posible.
proceso de transformación
proceso en línea
proceso padre
proceso primitivo
sistema orientado a datos
tabla de respuesta a eventoswww.xlibros.com

220 PARTE III • EL PROCESO DE ANÁLISIS
AGENTE DE
VIAJES
PRIVADO
AGENTE DE
VIAJES DE
AEROLÍNEA
TURISTA
CON PAGO
EN EFECTIVO
Revisar
crédito
Determinar
paseo
deseado
Hacer
reser-
vaciones
TURISTA
COSTO DE LOS PASEOS
FOLLETOS DE VIAJES
ITINERARIO DE VIAJE
HISTORIAL CREDITICIO
D1
1 2
3
D2
D3
D4
TURISTA
CON
TARJETA DE
CRÉDITO
FIGURA 7.EJ1
Bosquejo de un diagrama de flujo
de datos para Marilyn’s Tours.
5. Perfect Pizza desea instalar un sistema para registrar los pedidos de pizzas y alitas de pollo. Cuando los clientes
frecuentes llaman a Perfect Pizza por teléfono, se les pide su número telefónico. Cuando se introduce el número en una
computadora aparecen de manera automática el nombre, la dirección y la fecha del último pedido en la pantalla. Una vez
que se toma el pedido se calcula el total, incluyendo impuestos y envío. Después se pasa el pedido al cocinero. Luego se
imprime un recibo. Algunas veces se imprimen ofertas especiales, de manera que el cliente pueda obtener un descuento.
Los repartidores que hacen las entregas dan a los clientes una copia del recibo y un cupón (si hace falta). Se mantienen
los totales semanales para compararlos con el desempeño del año anterior. Escriba un resumen de las actividades de
negocios para tomar un pedido en Perfect Pizza.
6. Dibuje un diagrama de flujo de datos a nivel de contexto para Perfect Pizza (problema 5).
7. Expanda el diagrama a nivel de contexto en el problema 6 para mostrar todos los procesos importantes. Asigne a este
diagrama el nombre Diagrama 0. Debe ser un diagrama de flujo de datos lógico.
8. Dibuje un diagrama hijo lógico para el Diagrama 0 del problema 7, para el proceso que agrega un nuevo cliente si no se
encuentra en la base de datos (que nunca haya pedido algo de Perfect Pizza antes).
9. Dibuje un diagrama de flujo de datos físico para el problema 7.
10. Dibuje un diagrama de flujo de datos físico para el problema 8.
11. Particione el diagrama de flujo de datos físico en el problema 7; agrupe y separe los procesos según lo considere
apropiado. Explique por qué particionó el diagrama de flujo de datos de esa manera (recuerde que no tiene que
particionar todo el diagrama completo, sólo las partes que considere necesario particionar).
12. a. Dibuje un diagrama hijo lógico para el proceso 6 de la figura 7.17.
b. Dibuje un diagrama hijo físico para el proceso 6 de la figura 7.17.
13. Dibuje un diagrama de flujo de datos físico para el proceso 1.1 de la figura 7.18.
14. Cree un diagrama de contexto para un agente de bienes raíces que trate de crear un sistema que relacione a los
compradores con las casas que se adapten mejor a sus requerimientos.
15. Dibuje un diagrama de flujo de datos lógico que muestre los procesos generales para el problema 14. Asigne a este
diagrama el nombre Diagrama 0.
16. Cree un diagrama a nivel de contexto para facturar en un consultorio dental. Las entidades externas incluyen a los
pacientes y las compañías de seguros.
17. Dibuje un diagrama de flujo de datos lógico que muestre los procesos generales para el problema 16. Denomine a este
diagrama Diagrama 0.
18. Cree una tabla de respuestas a eventos para las actividades enlistadas para el sistema de procesamiento de pedidos de
World’s Trend.
19. Cree un caso de uso para la lista de siete procesos para el sistema de procesamiento de pedidos de World’s Trend.
20. Cree una matriz CRUD para los archivos de World’s Trend.
21. Use los principios del particionamiento para determinar cuáles procesos del problema 18 se deben incluir en programas
separados.www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 221
22. Cree un diagrama hijo de flujo de datos físico para la siguiente situación: el Grupo de usuarios de PC local sostiene
reuniones una vez al mes donde hay oradores informativos, premios de entrada y sesiones para grupos de interés
especial. Se lleva una computadora portátil a las reuniones, la cual se utiliza para agregar los nombres de los nuevos
miembros del grupo. El diagrama representa un proceso en línea y es el hijo del proceso 1, AGREGAR MIEMBROS
NUEVOS. Se incluyen las siguientes tareas:
a. Introducir la información del nuevo miembro.
b. Validar la información. Los errores se muestran en pantalla.
c. Cuando toda la información sea válida, aparecerá una pantalla de confirmación. El operador debe confirmar de
manera visual que todos los datos son correctos y debe aceptar o cancelar la transacción.
d. Las transacciones aceptadas agregan nuevos miembros al ARCHIVO MAESTRO DE MEMBRESÍAS, el cual se
guarda en el disco duro de la computadora portátil.
e. Las transacciones aceptadas se envían a un archivo DIARIO DE MEMBRESÍAS, el cual se guarda en un disco duro
secundario.
PROYECTOS EN GRUPO
1. Reúnase con su grupo para desarrollar un diagrama de flujo de datos a nivel de contexto para Maverick Transport (que
vimos por primera vez en el capítulo 4). Use los datos que haya generado posteriormente con su grupo sobre Maverick
Transport. (Sugerencia: concéntrese en una de las áreas funcionales de la empresa, en vez de tratar de modelar toda la
organización).
2. Use el diagrama a nivel de contexto que desarrolló en el problema 1 para desarrollar con su grupo un diagrama de flujo
de datos lógico de nivel 0 para Maverick Transport. Haga las suposiciones necesarias para dibujarlo. Elabore una lista de
ellas.
3. Seleccione con su grupo un proceso clave y expándalo en un diagrama hijo lógico. Haga las suposiciones necesarias para
dibujarlo. Elabore una lista de las preguntas de seguimiento y sugiera otros métodos para obtener más información sobre
los procesos que aún no le queden claros.
4. Use el trabajo que haya realizado su grupo a la fecha para crear un diagrama de flujo de datos físico de una parte del
nuevo sistema que piensa proponer a Maverick Transport.
BIBLIOGRAFÍA SELECCIONADA
Ambler, S. W. y L. L. Constantine (Eds.). The Unified Process Inception Phase: Best Practices for Implementing the Up.
Lawrence, KS: CMP Books, 2000.
Gane, C. y T. Sarson. Structured Systems Analysis and Design Tools and Techniques. Englewood Cliffs, NJ: Prentice Hall,
1979.
Hoffer, J. A., M. Prescott y H. Topi. Modern Database Management, 9ª. Edición. Upper Saddle River: Prentice Hall, 2009.
Kotonya, G. e I. Sommerville. Requirements Engineering: Processes and Techniques. Nueva York: John Wiley & Sons, 1999.
Lucas, H. Information Systems Concepts for Management, 3ª. Edición. Nueva York: McGraw-Hill, 1986.
Martin, J. Strategic Data-Planning Methodologies. Englewood Cliffs, NJ: Prentice Hall, 1982.
Thayer, R. H., M. Dorfman y D. Garr. Software Engineering: Vol. 1: The Development Process, 2ª. Edición. Nueva York: Wiley-
IEEE Computer Society Press, 2002.www.xlibros.com

222 PARTE III • EL PROCESO DE ANÁLISIS
E P I S O D I O 7
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Siguiendo el flujo
Después de recopilar y analizar los resultados de las entrevistas, cuestionarios y prototipos, Anna y Chip pasan a la siguiente etapa:
modelar el sistema. Su estrategia es crear un conjunto en capas de diagramas de flujos de datos y después describir los componentes.
Anna dice: “Vamos a agregar a los diagramas de flujo de datos lógicos actuales todos los requerimientos y características
deseadas del nuevo sistema. También podemos eliminar cualquiera de las características innecesarias que no se implementarían
en el nuevo sistema”.
A continuación, Anna agrega al diagrama a nivel de contexto (que se muestra en el caso de la CPU en el capítulo 2)
muchos de los informes, consultas y demás información que se incluirá en el nuevo sistema. En la figura E7.1 se muestra el
Sistema de
inventario de
computadoras
0
ID de computadora eliminada
Listado de instalaciones completadas
Información de modificación
de computadora
Mantenimiento
Administración
Administración
Informe de instalaciones
Informes administrativos
Respuestas a consultas
Informe de referencias
cruzadas de software
MantenimientoInformes de mantenimiento
Formulario de nueva computadora
Departamento
de envío/
recepción
Soporte
de oficina
Listado de computadoras recibidas
Informes detallados
Consultas de la administración
Consulta de software
Cuerpo
docente
Cuerpo
docente
Respuesta a una consulta
Usuario de
software
Informe de notificación de instalación
Formulario de software recibido
Listado de instalación
FIGURA E7.1
Diagrama de flujo de datos a
nivel de contexto del sistema
propuesto de inventario de
computadoras de la CPUwww.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 223
diagrama a nivel de contexto terminado. Observe los múltiples flujos nuevos de datos. En el sistema propuesto, el personal
de MANTENIMIENTO de computadoras recibirá los informes que no están disponibles en la actualidad. Por ejemplo, el
informe LISTADO DE INSTALACIÓN ayuda a automatizar la instalación de nuevas computadoras y otro informe adminis-
trativo llamado INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE muestra el software que se encuentra en cada
máquina.
Anna continúa: “Vamos a expandir esto en el Diagrama 0 para el nuevo sistema. Será un diagrama de flujo de datos lógico
debido a que nos enfocaremos en las necesidades de la empresa. Tal vez sería mejor si trabajáramos en equipo para este
diagrama”.
Después de trabajar durante varias horas esa tarde y una buena parte de la mañana siguiente, completan el diagrama. Lo
revisan y realizan pequeñas modificaciones. El Diagrama 0 terminado se muestra en la figura E7.2 y en la figura E7.3. Como
Registro de
computadora
Agregar
computadora
nueva
2
D6 Pedidos de computadoras
pendientes
Pedido
pendiente
Departamento
de envío/
recepción
Formulario de nueva computadora
Mantenimiento
Listado de instalación
Soporte
de oficina
Listado de computadoras recibidas
Administración
Informe de
instalación
Instalar
computadora
5
Producir
informe
de referencias
cruzadas de
hardware/
software
9
D4 Archivo maestro
de computadoras
Nueva
computadora
Nuevo
software
Agregar
registro de
software
1
D5 Archivo maestro de
software
Registro
de software
Lista de
instalación
de software
Formulario de software
recibido Departamento
de envío/
recepción
Instalar
software
8
Informe de notificación
de instalación
Usuario de
software
D6 Pedidos de computadoras
pendientes
Modificar
computadora
6
Mantenimiento
Listado de
instalaciones
completas
Información de
modificación
de computadora
Actualización de
instalación
Computadora
modificada
Actualización de
instalación
Administración
Informe de referencias
cruzadas de software
FIGURA E7.2
Diagrama 0: Sistema
propuesto de inventario
de computadoras de la
CPU (parte 1).www.xlibros.com

224 PARTE III • EL PROCESO DE ANÁLISIS
es un diagrama lógico, no muestra ningún método físico de entrada de datos ni operaciones de validación; tampoco muestra
almacenes de datos temporales o archivos de transacciones. La sincronización no es un problema (un ejemplo es el proceso
AGREGAR COMPUTADORA NUEVA, en donde parece que los pedidos se actualizan y los informes se producen al mismo
tiempo).
“Por fin esto se ve bien”, reflexiona Chip. “Todos los procesos importantes, los flujos de datos y los almacenes de datos
están incluidos. Y el diagrama en general no se ve muy complicado”.
“Fue útil colocar todas las consultas en un subsistema y todos los informes en otro. ¿Recuerdas lo complicado que era el
diagrama original?”, pregunta Anna.
“Desde luego”, responde Chip. “Hasta llegué a pensar que estábamos tratando de abarcar mucho con este sistema. Por lo
menos ahora es más manejable. Ya que lo terminamos, ¿cuál es el siguiente paso?”.
“Necesitamos describir el Diagrama 0 con más detalle”, comenta Anna. “Para ello vamos a dibujar un diagrama de
nivel 1 para cada uno de los procesos en el Diagrama 0. Así como un padre puede tener muchos hijos, puede haber muchos
diagramas de nivel 1 para un diagrama específico de nivel 0. Por esta razón, muchos analistas los llaman diagramas padres
e hijos”.
“He estado trabajando en el Diagrama 1, una expansión del proceso 1 que se llama AGREGAR REGISTRO DE SOFT-
WARE. Tal vez te gustaría revisar el resultado final”, comenta Anna. En la figura E7.4 se muestra este Diagrama 1.
Chip y Anna utilizan Visible Analyst para verificar que la sintaxis del diagrama de flujo de datos sea correcta. Visible
Analyst también comprobará el balance de los niveles entre los procesos del diagrama de flujo de datos y los diagramas
hijos.
Eliminar
computadora
4ID de
computadora
eliminada
ID de computadora
eliminada
Informes
administrativos
Registro de hardware
Subsistema
de informes
3
Registro de software
Registro de software
Informes de
mantenimiento
Informe detallado
7
Subsistema
de consultas
Respuestas a
consultas
Consultas de la
administración
Registro de hardware
Consulta de
software
Respuesta
a consulta
Mantenimiento
Soporte
de oficina
Administración
Cuerpo
docente
D4 Archivo maestro de
computadoras
D5 Archivo maestro
de software
D4 Archivo maestro
de computadoras
FIGURA E7.3
Diagrama 0: Sistema propuesto de
inventario de la CPU (parte 2).www.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 225
Registro
de software
Teclear
registro de
software
1.1Formulario de
software recibido
D5 Archivo maestro
de software
Validar
registro de
software
1.2
Confirmar
nuevo
software
1.3
Software tecleado
Software
válido
Crear archivo
de registros
de software
1.4
Software confirmado
Entrada en el
registro de
software
Listado de instalación
de software
D7 Archivo de registro
de software
Crear listado
de instalación
de software
1.6
Entrada en el
registro de
software
Agregar
nuevo
registro de
software
1.5
D5 Archivo maestro
de software
Nuevo
software
Software confirmado
FIGURA E7.4
Diagrama 1: AGREGAR
REGISTRO DE
SOFTWARE del sistema
computarizado propuesto
para la CPU.
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver el diagrama a nivel de contexto para el sistema computarizado propuesto. Si
utiliza Visible Analyst, experimente con los controles Zoom en la barra de herramientas inferior para cambiar de la vista
global a una vista detallada del diagrama. Haga doble clic en el proceso central para examinar la entrada en el repositorio
para éste. Haga clic en Exit para regresar al diagrama. Haga clic con el botón derecho en el proceso central para mostrar el
menú de objetos para el proceso central. Use la opción Explode para mostrar el Diagrama 0, el cual representa los detalles
del proceso central. Maximice la ventana y haga doble clic en algunos de los almacenes y flujos de datos para examinar sus
entradas en el repositorio. Haga clic en Exit para regresar al diagrama. Haga un acercamiento al 100 por ciento y desplácese
por la pantalla para ver las distintas regiones del diagrama; después imprima el diagrama usando una orientación panorá-
mica. Haga clic en FILE, NEST y PARENT para regresar al diagrama a nivel de contexto. Maximice la ventana.
E-2. Modifique el Diagrama 0 del sistema computarizado propuesto. Agregue el proceso 10, ACTUALIZAR REGISTRO DE
SOFTWARE. Tendrá que mover la entidad externa ADMINISTRACIÓN más abajo en el diagrama; colóquela a la iz-
quierda del proceso 7, SUBSISTEMA DE CONSULTAS. Cree una entrada en el repositorio para el proceso y después
haga clic en Exit para regresar al diagrama. Imprima el diagrama usando una orientación panorámica.www.xlibros.com

226 PARTE III • EL PROCESO DE ANÁLISIS
Entrada: 1. DATOS DE MODIFICACIÓN DE SOFTWARE, de SOPORTE DE OFICINA
2. ID DE ELIMINACIÓN DE SOFTWARE, de ADMINISTRACIÓN
Salida: 1. REGISTRO DE SOFTWARE, una actualización del almacén de datos ARCHIVO MAESTRO DE
SOFTWARE
E-3. Modifique el Diagrama 10, ACTUALIZAR REGISTRO DE SOFTWARE. Para conectarse al ARCHIVO MAESTRO
DE SOFTWARE use una flecha con doble punta (si utiliza Visible Analyst, haga clic con el botón derecho en el flujo de
datos, seleccione Change Item, después seleccione Change Type y Terminator Type, Double Filled). Imprima el
diagrama final.
E-4. Modifique el diagrama 8, INSTALAR SOFTWARE. Agregue los siguientes procesos. Haga un acercamiento y desplá-
cese por la pantalla; revise que su diagrama tenga una apariencia profesional. Imprima el resultado final.
E-5. Modifique el Diagrama 6, MODIFICAR REGISTRO DE COMPUTADORA. Éste es un programa en línea para modifi-
car la información de la computadora. Agregue los siguientes tres procesos. Cree entradas en el repositorio para cada uno
de los procesos, así como para el flujo de datos. Al terminar, haga un acercamiento al 100 por ciento y modifique las
flechas de flujo de datos que no estén derechas; además desplace las etiquetas de flujo de datos para obtener un gráfico
con apariencia profesional. Imprima el diagrama; use la orientación panorámica.
a. Proceso 6.6, VALIDAR MODIFICACIONES. Este proceso edita cada campo de modificación para verificar su
validez. La entrada es CAMBIOS TECLEADOS. Los campos de salida son ERRORES DE MODIFICACIÓN (flujo
de interfaz) y MODIFICACIONES VÁLIDAS (al proceso 6.7).
b. Proceso 6.7, CONFIRMAR MODIFICACIONES. Este proceso es una confirmación visual de las modificaciones.
El operador tiene la oportunidad de rechazar las modificaciones o aceptarlas. La entrada es MODIFICACIONES
VÁLIDAS. Los campos de salida son MODIFICACIONES RECHAZADAS (flujo de interfaz) y MODIFICA-
CIONES CONFIRMADAS (al proceso 6.8).
c. Proceso 6.8, REESCRIBIR ARCHIVO MAESTRO DE COMPUTADORAS. Este proceso reescribe el registro del
ARCHIVO MAESTRO DE COMPUTADORAS con las modificaciones realizadas al mismo. La entrada es MODI-
FICACIONES CONFIRMADAS. El flujo de salida es el registro del ARCHIVO MAESTRO DE COMPUTADO-
RAS, al almacén de datos ARCHIVO MAESTRO DE COMPUTADORAS.
E-6. Cree el diagrama de flujo de datos hijo para el proceso 4, ELIMINAR COMPUTADORA. La siguiente tabla sintetiza la
entrada, el proceso y la salida. Describa cada proceso y flujo de datos en el repositorio. Al terminar haga un acercamiento
al 100 por ciento, mueva las líneas de flujo de datos que no estén alineadas en forma correcta, desplace las etiquetas de
flujo de datos para obtener un gráfico con apariencia profesional e imprima el diagrama.
Proceso: 8.2 INSTALAR SOFTWARE DE COMPUTADORA
Entrada: 1. UBICACIÓN DE COMPUTADORA, del proceso 8,1
2. TÍTULO Y VERSIÓN DE SOFTWARE, del proceso 8.1
Salida: 1. FORMULARIO DE SOFTWARE INSTALADO
Proceso: 8.3 CREAR TRANSACCIÓN DE SOFTWARE INSTALADO
Entrada: 1. FORMULARIO DE SOFTWARE INSTALADO
Salida: 1. TRANSACCIÓN DE SOFTWARE INSTALADO, al almacén de datos de SOFTWARE INSTALADO
Proceso: 8.4 ACTUALIZAR ARCHIVO MAESTRO DE SOFTWARE
Entrada: 1. TRANSACCIÓN DE SOFTWARE INSTALADO
Salida: 1. ARCHIVO MAESTRO DE SOFTWARE, actualizar
Proceso: 8.5 PRODUCIR NOTIFICACIÓN DE INSTALACIÓN
Entrada: 1. TRANSACCIÓN DE SOFTWARE INSTALADO
2. ARCHIVO MAESTRO DE SOFTWARE, del almacén de datos ARCHIVO MAESTRO DE
SOFTWARE
3. ARCHIVO MAESTRO DE HARDWARE, del almacén de datos ARCHIVO MAESTRO DE
COMPUTADORAS
Salida: 1. LISTADO DE NOTIFICACIÓN DE INSTALACIÓN, un flujo de interfazwww.xlibros.com

CAPÍTULO 7 • USO DE DIAGRAMAS DE FLUJO DE DATOS 227
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
Proceso: 4.1 TECLEAR ID DE ELIMINACIÓN
Descripción: El ID de computadora se tecla en forma interactiva
Entrada: 1. ID DE COMPUTADORA ELIMINADA
Salida: 1. ELIMINACIÓN TECLEADA
Proceso: 4.2 OBTENER REGISTRO DE COMPUTADORA
Descripción: Se lee el registro del ARCHIVO MAESTRO DE COMPUTADORAS para asegurar que exista
Entrada: 1. ELIMINACIÓN TECLEADA (interfaz)
2. REGISTRO DE COMPUTADORA, del almacén de datos ARCHIVO MAESTRO DE
COMPUTADORAS
Salida: 1. ERROR: NO SE ENCONTRÓ (interfaz)
2. REGISTRO DE COMPUTADORA VÁLIDO
Proceso: 4.3 CONFIRMAR ELIMINACIÓN DE COMPUTADORA
Descripción: La información de la computadora se muestra en la pantalla para que el operador confirme o rechace
la eliminación.
Entrada: 1. REGISTRO DE COMPUTADORA VÁLIDO
Salida: 1. ELIMINACIÓN RECHAZADA (interfaz)
2. ELIIMINACIÓN CONFIRMADA
Proceso: 4.4 ELIMINAR REGISTRO DE COMPUTADORA
Descripción: El registro de computadora se elimina en forma lógica (no física) del almacén de datos ARCHIVO
MAESTRO DE COMPUTADORAS al reescribir el registro con una I de inactivo en el campo
Código de registro
Entrada: 1. ELIMINACIÓN CONFIRMADA
Salida: 1. COMPUTADORA ELIMINADA, una flecha con doble punta al almacén de datos ARCHIVO
MAESTRO DE COMPUTADORAwww.xlibros.com

C A P Í T U L O 8
Análisis de sistemas mediante
el uso de diccionarios de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Entender la manera en que los diccionarios de datos se emplean para analizar sistemas
orientados a objetos.
2. Crear entradas en el diccionario de datos para los procesos de datos, almacenes, flujos
y estructuras, además de los elementos lógicos y físicos de los sistemas que se
estudian, con base en los DFD.
3. Comprender el concepto de un repositorio para la información de los proyectos de los
analistas y el rol de las herramientas CASE en cuanto a su creación.
4. Reconocer las funciones de los diccionarios de datos para ayudar a los usuarios a
actualizar y dar mantenimiento a los sistemas de información.
Después de elaborar correctamente diagramas de flujo de datos de varios
niveles, los analistas los emplean para clasificar los procesos de datos,
flujos, almacenes, estructuras y elementos en un diccionario de datos. De
particular importancia son los nombres que se utilizan para caracterizar los
elementos de datos: el analista encargado de la denominación de los com-
ponentes de los sistemas orientados a datos debe esforzarse para que el
nombre sea significativo y exclusivo. En este capítulo veremos el diccionario de datos, otro
método para ayudar en el análisis de los sistemas orientados a datos.
EL DICCIONARIO DE DATOS
El diccionario de datos es una versión especializada de los diccionarios que se utilizan como
referencias en la vida cotidiana. El diccionario de datos es una obra de consulta de información
sobre los datos (es decir, metadatos); es compilado por los analistas de sistemas para guiarse
a través del análisis y diseño. Como documento, el diccionario de datos recopila y coordina
términos de datos específicos, además de confirmar lo que significa cada término para distintas
personas en la organización. Los diagramas de flujo de datos que vimos en el capítulo 7 son un
excelente punto de partida para recolectar entradas para el diccionario de datos.
Una razón importante para tener un diccionario es con el fin de mantener limpios los datos;
es decir, para conservarlos consistentes. Si usted almacena datos sobre el sexo de un hombre
como “M” en un registro, “Masculino” en un segundo registro y como el número “1” en un tercer
registro, los datos no están “limpios”. En este aspecto el diccionario de datos le será muy útil.
Los diccionarios de datos automatizados (parte de las herramientas CASE que menciona-
mos antes) son valiosos por su capacidad de realizar referencias cruzadas con los elementos de
datos para permitir los cambios necesarios en todos los programas que compartan un elemento
común. Gracias a esta característica ya no hay necesidad de modificar los programas al azar ni
esperar hasta que el programa no se ejecute debido a un cambio que no se implementó en todos
los programas que compartan el elemento actualizado. Es evidente que los diccionarios de datos
automatizados son importantes para los sistemas extensos que producen varios miles de elemen-
tos de datos para clasificarlos y usarlos en referencias cruzadas.
228www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 229
Necesidad de comprender el diccionario de datos
En la actualidad, muchos sistemas de administración de bases de datos vienen equipados con un diccionario de
datos automatizado. Estos diccionarios pueden ser elaborados o simples. Algunos diccionarios de datos compu-
tarizados clasifican de manera automática los elementos de datos al momento de llevar a cabo la programación;
otros simplemente proveen una plantilla en la que se pide a la persona que llena el diccionario clasificar todas las
entradas de una manera uniforme.
A pesar de la existencia de los diccionarios de datos automatizados, las cuestiones que siguen siendo per-
tinentes para el analista de sistemas durante el esfuerzo de sistemas son comprender qué datos componen un
diccionario de datos, las convenciones utilizadas en los diccionarios de datos y la forma en que se desarrolla
un diccionario de datos. Al comprender el proceso de compilar un diccionario de datos, el analista de sistemas
puede conceptualizar con más facilidad el sistema y la forma en que funciona. En las siguientes secciones permi-
tiremos al analista ver el razonamiento detrás de lo que existe en los diccionarios de datos automatizados.
Además de proveer documentación y eliminar la redundancia, podemos usar el diccionario de datos para:
1. Validar la integridad y precisión del diagrama de flujo de datos.
2. Proveer un punto de partida para desarrollar pantallas e informes.
3. Determinar el contenido de los datos almacenados en archivos.
4. Desarrollar la lógica para los procesos del diagrama de flujo de datos.
5. Crear XML (lenguaje de marcado extensible).
EL REPOSITORIO DE DATOS
Aunque el diccionario de datos contiene información sobre los datos y procedimientos, hay una colección más
grande de información sobre el proyecto: el repositorio. El concepto de repositorio es uno de las muchas implica-
ciones de las herramientas CASE y puede contener lo siguiente:
1. Información sobre los datos que mantiene el sistema, incluyendo flujos de datos, almacenes de datos,
estructuras de registros, elementos, entidades y mensajes.
2. Lógica de procedimiento y casos de uso.
3. Diseño de pantallas e informes.
4. Relaciones de datos, como la forma en que una estructura de datos está vinculada con otra.
5. Requerimientos del proyecto y entregables finales del sistema.
6. Información administrativa del proyecto, como calendarios de entrega, logros, cuestiones que hay que
resolver y usuarios del proyecto.
Para crear el diccionario de datos hay que examinar y describir el contenido de los flujos de datos, los almacenes de
datos y los procesos, como se muestra en la figura 8.1. Hay que definir cada almacén y flujo de datos, para des-
pués expandirlo de manera que incluya los detalles de los elementos que contiene. Debemos describir la lógica
Diagrama de flujo de datos
Almacén de datos
Flujo de datos
Diccionario de datos
Formulario de
descripción
de flujo
datos
XXX
Estructura
de datos
XXX
Formulario
de descripción
de almacén
de datos
XXX
Elementos
de datos
XXX
Estructura
de datos
XXX
Elementos
de datos
XXX
FIGURA 8.1
Cómo se relacionan los diccionarios de datos con los diagramas de flujo de datos.www.xlibros.com

230 PARTE III • EL PROCESO DE ANÁLISIS
de cada proceso mediante el uso de los datos que entran o salen del proceso. Hay que identificar y resolver las
omisiones y otros errores de diseño.
Hay que desarrollar las cuatro categorías del diccionario de datos (flujos de datos, estructuras de datos, ele-
mentos de datos y almacenes de datos) para promover la comprensión de los datos del sistema. En el capítulo 9
presentaremos la lógica de procedimiento, en el capítulo 13 hablaremos sobre las entidades y los capítulos 2 y 10
corresponden a los mensajes y casos de uso.
Para ilustrar la forma en que se crean las entradas en el diccionario de datos, vamos a usar un ejemplo para
la División de catálogos de World’s Trend. Esta empresa vende ropa y otros artículos por correo mediante el uso
de un sistema de pedidos vía telefónica (el formulario de pedido por correo también se puede enviar vía fax), y
a través de Internet por medio de formularios Web personalizados. Sin importar dónde se origine el pedido, los
datos subyacentes capturados por el sistema son iguales para los tres métodos.
El formulario de pedido de World’s Trend que se muestra en la figura 8.2 proporciona algunas pistas sobre
lo que se debe introducir en un diccionario de datos. En primer lugar hay que capturar y almacenar nombre, di-
rección y número telefónico de la persona que está haciendo el pedido. Después hay que tratar con los detalles
del pedido: la descripción del artículo, el tamaño, color, precio, cantidad, etcétera. También hay que determinar
el método de pago del cliente. Una vez hecho todo esto, podemos guardar estos datos para usarlos en el futuro.
Usaremos este ejemplo en todo el capítulo para ilustrar cada una de las partes del diccionario de datos.
Definición de los flujos de datos
Por lo general, se define primero los flujos de datos. Las entradas y salidas del sistema se determinan a partir
de las entrevistas, de observar a los usuarios y analizar los documentos además de otros sistemas existentes.
Podemos sintetizar la información que se captura para cada flujo de datos mediante el uso de un formulario que
contenga la siguiente información:
1. ID, un número de identificación opcional. Algunas veces el ID se codifica mediante un esquema para
identificar al sistema y la aplicación en el mismo.
2. Un nombre descriptivo único para este flujo de datos. Este nombre es el texto que debe aparecer en el
diagrama y se debe referenciar en todas las descripciones que utilicen el flujo de datos.
3. Una descripción general del flujo de datos.
4. El origen del flujo de datos. Este origen puede ser una entidad externa, un proceso o un flujo de datos que
provenga de un almacén de datos.
5. El destino del flujo de datos (los mismos elementos enlistados bajo el origen).
6. Una indicación para determinar si el flujo de datos es un registro que entra o sale de un archivo, o un registro
que contiene un informe, formulario o pantalla. Si el flujo de datos contiene información que se utiliza entre
procesos, se designa como interno.
7. El nombre de la estructura de datos que describe a los elementos que se encuentran en este flujo de datos.
Para un flujo de datos simple, podrían ser uno o varios elementos.
8. El volumen por unidad de tiempo. Los datos podrían ser registros por día o cualquier otra unidad de tiempo.
9. Un área para comentarios adicionales y anotaciones sobre el flujo de datos.
FIGURA 8.2
Un pedido en línea de la División
de catálogos de World’s Trend.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 231
Una vez más podemos usar nuestro ejemplo de la División de catálogos de World’s Trend del capítulo 7 para
ilustrar un formulario completo. La figura 8.3 es un ejemplo de la descripción del flujo de datos que representa
la pantalla utilizada para agregar un nuevo PEDIDO DEL CLIENTE y para actualizar los archivos de clientes y
artículos. Cabe mencionar que la entidad externa CLIENTE es el origen y que PROCESO 1 es el destino, que
provee un vínculo de vuelta al diagrama de flujo de datos. La casilla marcada como “Pantalla” indica que el flujo
representa una pantalla de entrada. Podría ser cualquier pantalla, como una página Web, una interfaz gráfica de
usuario (GUI), un teléfono celular o tal vez una pantalla de mainframe. La descripción detallada del flujo de datos
podría aparecer en este formulario, o se podría representar como una estructura de datos.
Hay que describir primero los flujos de datos para todas las entradas y salidas, ya que por lo general repre-
sentan la interfaz humana; después, los flujos de datos intermedios y los flujos de datos que entran y salen de los
almacenes de datos. Para describir los detalles de cada flujo de datos usamos elementos (a los que algunas veces
se les denomina campos), una estructura de datos o un grupo de elementos.
Podemos describir un flujo de datos simple mediante el uso de un solo elemento, como el número de cliente
que utiliza un programa de consulta para buscar el correspondiente registro de cliente.
Descripción de las estructuras de datos
Por lo general, para describir las estructuras de datos utilizamos la notación algebraica. Este método permite al
analista producir una vista de los elementos que forman la estructura de datos, junto con la información sobre los
mismos. Por ejemplo, el analista indicará si hay muchos elementos iguales en la estructura de datos (un grupo
repetitivo) o si pueden existir dos elementos mutuamente excluyentes de cada uno de los otros elementos. La
notación algebraica utiliza los siguientes símbolos:
1. Un signo de igual () significa “está compuesto de”.
2. Un signo positivo () significa “y”.
3. Las llaves { } indican elementos repetitivos, también conocidos como grupos repetitivos o tablas repetitivas.
Puede haber un elemento repetitivo o varios de ellos en el grupo. El grupo repetitivo puede tener
condiciones, como un número fijo de repeticiones, o límites superiores e inferiores para el número de
repeticiones.
Cliente Proceso 1
Pedido del cliente
Contiene la información del pedido de un cliente y se utiliza para
actualizar el archivo maestro del cliente y al archivo de artículos; además se
usa para producir un registro de pedido.
ID
Nombre
Descripción
Descripción de flujo de datos
Comentarios
Origen Destino
Tipo de flujo de datos
Archivo Pantalla Informe Formulario Interno
Estructura de datos que viaja con el flujo Volumen/Tiempo
Información del pedido 10/hora
Información del registro de pedido para un pedido del cliente.
El pedido se puede recibir a través de Web, por correo electrónico o FAX.
También es posible que el cliente llame por teléfono directamente al
departamento de procesamiento de pedidos.
FIGURA 8.3
Ejemplo de estructura de datos
para agregar el pedido de un
cliente en la División de catálogos
de World’s Trend.www.xlibros.com

232 PARTE III • EL PROCESO DE ANÁLISIS
4. Los corchetes [ ] representan una situación del tipo cualquiera/o (either/or). Puede estar presente cualquier
elemento u otro, pero no ambos. Los elementos que se enlistan entre corchetes son mutuamente excluyentes.
5. Los paréntesis ( ) representan un elemento opcional. Los elementos opcionales se pueden dejar en blanco en
las pantallas de entrada de datos y pueden contener espacios o ceros para los campos numéricos en las
estructuras de archivos.
La figura 8.4 es un ejemplo de la estructura de datos para agregar el pedido de un cliente en la División de catálogos
de World’s Trend. Cada pantalla CLIENTE NUEVO consiste en las entradas que se encuentran del lado derecho de
los signos de igual. Algunas de las entradas son elementos, pero otras, como NOMBRE DEL CLIENTE, DIREC-
CIÓN y TELÉFONO, son grupos de elementos o registros estructurales. Por ejemplo, NOMBRE DEL CLIENTE
está compuesto por PRIMER NOMBRE, INICIAL SEGUNDO NOMBRE y APELLIDO PATERNO. Hay que
definir cada registro estructural de una manera más detallada hasta que todo el conjunto se descomponga en sus ele-
mentos básicos. Cabe mencionar que, después de la definición para la pantalla PEDIDO DEL CLIENTE, están las
definiciones para cada registro estructural. Incluso un campo tan simple como NÚMERO TELEFÓNICO se define
como una estructura para que el código de área se pueda procesar por separado.
Pedido del cliente = Número del cliente +
Nombre del cliente +
Dirección +
Teléfono +
Número de catálogo +
Fecha del pedido +
(Artículos del pedido disponibles) +
Total de mercancía +
(Impuestos) +
Envío y manejo +
Total del pedido +
Método de pago +
(Tipo de tarjeta de crédito) +
(Número de tarjeta de crédito) +
(Fecha de expiración)
Nombre del cliente = Primer nombre +
(Inicial segundo nombre) +
Apellido paterno
Dirección = Calle +
(Departamento) +
Ciudad +
Estado +
CP +
(Expansión CP) +
(País)
Teléfono = Código de área +
Número local
Artículos del pedido
disponibles =
Cantidad ordenada +
Número de artículo +
Descripción de artículo +
Tamaño +
Color +
Precio +
Total de artículo
Método de pago = [Cheque | Crédito | Giro postal]
Tipo de tarjeta de
crédito =
[World’s Trend | American Express | MasterCard | Visa]
FIGURA 8.4
Ejemplo de estructura de datos
para agregar el pedido de un
cliente en la División de catálogos
de World’s Trend.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 233
Los registros estructurales y elementos que se utilizan en muchos sistemas reciben un nombre específico que
no es del sistema como calle, ciudad y código postal, lo cual no refleja el área funcional en la que se utilizan.
Este método permite al analista definir estos registros una vez y usarlos en muchas aplicaciones. Por ejemplo,
una ciudad puede ser la ciudad de un cliente, un proveedor o un empleado. Observe el uso de los paréntesis para
indicar que (INICIAL SEGUNDO NOMBRE), (DEPARTAMENTO) y (EXPANSIÓN CP) son información op-
cional de PEDIDO (pero no más de uno). Para indicar la condición O hay que encerrar las opciones en corchetes
y separarlas con el símbolo .
Estructuras de datos lógicas y físicas
Cuando se definen las estructuras de datos por primera vez, se incluyen sólo los elementos de datos que el
usuario puede ver, como nombre, dirección y saldo actual. Esta etapa es el diseño lógico que muestra lo que la
empresa necesita para sus operaciones diarias. Como aprendimos de la HCI, es importante que el diseño lógico
refleje con precisión el modelo mental de la forma en que el usuario ve el sistema. Al utilizar el diseño lógico como
base, el analista puede diseñar las estructuras de datos físicas, que incluyen los elementos adicionales necesarios
para implementar el sistema. Los siguientes son ejemplos de elementos de diseño físicos:
1. Los campos clave que se utilizan para localizar registros en la tabla de una base de datos. Un ejemplo es un
número de artículo, que la empresa no necesita para operar pero es necesario para definir y localizar los
registros de computadora.
2. Los códigos para identificar el estado de los registros maestros, como si un empleado está activo (si trabaja
en la actualidad) o inactivo. Podemos mantener dichos códigos en archivos que produzcan información
fiscal.
3. Los códigos de transacción se utilizan para identificar los tipos de registros cuando un archivo contiene
distintos tipos de éstos. Un ejemplo es un archivo de créditos que contiene registros para los artículos
devueltos, así como registros de pagos.
4. Las entradas de grupos repetitivos que contienen el conteo de los elementos en el grupo.
5. Los límites en cuanto al número de elementos en un grupo repetido.
6. La contraseña que utiliza un cliente para acceder a un sitio Web seguro.
La figura 8.5 es un ejemplo de la estructura de datos para un ESTADO DE CUENTA DE FACTURACIÓN
DE CLIENTE y muestra que la LÍNEA DE PEDIDO es tanto un elemento repetitivo como un registro estructu-
ral. Los límites de LÍNEA DE PEDIDO son del 1 al 5 para indicar que el cliente puede ordenar de uno a cinco
artículos en esta pantalla. Los artículos adicionales aparecerán en pedidos subsiguientes.
La notación de grupo repetitivo puede tener varios formatos adicionales. Si el grupo se repite un número
fijo de veces, ese número se coloca a un lado de la llave de apertura, como en 12 {Ventas mensuales}, donde
siempre hay 12 meses en el año. Si no se indica un número, el grupo se repite en forma indefinida. Un ejem-
plo es una tabla que contiene un número indefinido de registros, como Tabla maestra de clientes = {Registros
de clientes}.
El número de entradas en los grupos repetitivos también puede depender de una condición, como una en-
trada en el Registro maestro de clientes por cada artículo ordenado. Esta condición se podría guardar en el dic-
cionario de datos como {Artículos comprados} 5, donde 5 es el número de artículos.
Estado de cuenta de
facturación de cliente =
Fecha actual +
Número de cliente +
Nombre del cliente +
Dirección +
{Línea de pedido} +
(Monto de pago anterior) +
Total monto deudor +
(Comentario)
Línea de pedido = Número de pedido +
Fecha de pedido +
Total del pedido
5
1
FIGURA 8.5
Elementos físicos agregados a una
estructura de datos.www.xlibros.com

234 PARTE III • EL PROCESO DE ANÁLISIS
Elementos de datos
Cada elemento de datos se debe definir una vez en el diccionario de datos y también se puede introducir previa-
mente en el formulario de descripción de un elemento, como el que se muestra en la figura 8.6. Las característi-
cas que se incluyen comúnmente en el formulario de descripción de elemento son:
1. ID de elemento. Esta entrada opcional permite al analista crear entradas automatizadas en el diccionario de
datos.
2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en la manera común en que la
mayoría de los programas o el usuario principal llamen a ese elemento.
3. Los alias, que son sinónimos u otros nombres para el elemento. Los alias son nombres que utilizan distintos
usuarios en distintos sistemas. Por ejemplo, un NÚMERO DE CLIENTE también se puede llamar
NÚMERO DE CUENTA POR COBRAR o NÚMERO DE CONSUMIDOR.
4. Una descripción corta del elemento.
5. Si el elemento es base o derivado. Un elemento base es el que se teclea al sistema en un principio, como el
nombre de un cliente, la dirección o ciudad. Los elementos base se deben almacenar en archivos. Los
elementos derivados se crean a través de los procesos como resultado de un cálculo o una serie de
instrucciones de toma de decisiones.
6. La longitud de un elemento. Algunos elementos tienen longitudes estándar. Por ejemplo, en los Estados
Unidos todas las longitudes para las abreviaturas de los nombres de estados, códigos postales y números
telefónicos son iguales. Para otros elementos, las longitudes pueden variar, por lo que el analista y la
Número de cliente
Número de consumidor
Número de cuenta por cobrar
Identifica en forma única a un cliente que haya realizado una
transacción de negocios durante los últimos cinco años.
ID
Nombre
Alias
Alias
Descripción
Formulario de descripción de elemento
Longitud Punto dec. Alfabético
Formato de entrada Alfanumérico
Formato de salida FechaValor predeterminado Numérico
Continuo o Discreto Base o Derivado
Comentarios
Características del elemento
6
9 (6)
9 (6)
Criterios de validación
Continuo
Límite
superior
Límite
inferior
<999999
>0
Discreto
Valor Significado
El número de cliente debe pasar una prueba de dígito de verificación
módulo-11. Es derivado debido a que es generado por computadora y se
agrega un dígito de verificación.
FIGURA 8.6
La descripción de un elemento
de la División de catálogos de
World’s Trend.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 235
comunidad de usuarios deben decidir en conjunto sobre la longitud final con base en las siguientes
consideraciones:
a. Para determinar las longitudes de cantidades numéricas hay que averiguar el número más grande que
puede llegar a contener esa cantidad y después permitir un espacio razonable de expansión.
b. Los campos de nombres y direcciones pueden recibir longitudes con base en la siguiente tabla. Por
ejemplo, el campo de un apellido de 11 caracteres puede alojar al 98 por ciento de los apellidos paternos
en los Estados Unidos.
c. Para otros campos, a menudo es conveniente examinar o sacar una muestra de los datos históricos que se
encuentran en la organización para determinar una longitud de campo apropiada.
Si el elemento es demasiado pequeño, se truncarán los datos que se introduzcan. El analista debe decidir
cómo afectará eso a las salidas del sistema. Por ejemplo, si se trunca el apellido paterno de un cliente, de
todas formas se entregaría el correo; pero si se trunca la dirección de correo electrónico, se devolverá como
no encontrado.
7. El tipo de datos: numérico, fecha, alfabético, carácter variable (varchar) o carácter, que algunas veces se
denomina alfanumérico o datos de texto. Los datos de caracteres variables (varchar) pueden contener
cualquier número de caracteres, hasta un límite establecido por el software de base de datos. Al usar
caracteres variables es opcional especificar la longitud. En la figura 8.7 se muestran varios de estos
formatos. Los campos de caracteres pueden contener una mezcla de letras, números y caracteres especiales.
Si el elemento es una fecha, hay que determinar su formato (por ejemplo, MMDDAAAA). Si el elemento es
numérico, hay que determinar su tipo de almacenamiento.
Los formatos de computadora personal, como moneda, número o científico, dependen de la forma en
que se vayan a utilizar los datos. Los formatos de números se pueden clasificar como entero, entero largo,
precisión simple, precisión doble, etcétera. Hay muchos otros tipos de formatos utilizados con los sistemas
Tipo de datos
Bit Un valor de 1 o 0, un valor de verdadero/falso
Char, varchar, text Cualquier carácter alfanumérico
Datetime, smalldatetime Datos alfanuméricos, varios formatos
Decimal, numérico Datos numéricos con precisión hasta el dígito menos
significativo; pueden contener una porción entera y
una porción decimal
Float, real Valores de punto flotante que contienen un valor
decimal aproximado
Int, smallint, tinyint Sólo datos enteros (dígitos completos)
Binary, varbinary, image Cadenas binarias (sonido, imágenes, video)
Cursor, timestamp, uniqueidentifier Un valor que siempre es único dentro de una base de datos
Autonumber Un número que siempre se incrementa en uno cuando se
agrega un registro a una tabla de base de datos
Currency, money, smallmoney Números monetarios con precisión de cuatro lugares decimales
Significado FIGURA 8.7
Algunos ejemplos de formatos de
datos utilizados en sistemas de PC.
Campo Longitud Porcentaje de datos que podrán
caber (EE.UU.)
Apellido paterno 11 98
Primer nombre 18 95
Nombre de empresa 20 95
Calle 18 90
Ciudad 17 99www.xlibros.com

236 PARTE III • EL PROCESO DE ANÁLISIS
Carácter de formato Significado
Puede introducir o visualizar/imprimir cualquier carácter
Se pueden introducir o visualizar sólo números
Visualiza los ceros a la izquierda como espacios
Inserta comas al visualizar números
Inserta un punto al visualizar un número
Inserta barras diagonales al visualizar un número
Inserta un guión corto al visualizar un número
Indica una posición decimal (cuando no se incluye el punto decimal)
X
9
Z
,
·
/
-
V
FIGURA 8.8
Códigos de formato de caracteres.
de PC. Unicode es un sistema de codificación estandarizado para definir símbolos gráficos, como los
caracteres chinos o japoneses. En un capítulo posterior describiremos Unicode con más detalle. Hay tres
formatos estándar para computadoras mainframe: decimal por zonas, decimal empaquetado y binario. El
formato decimal por zonas se utiliza para imprimir y visualizar datos. El formato decimal empaquetado se
utiliza comúnmente para ahorrar espacio en las distribuciones de los archivos y para elementos que
requieren un alto nivel de operaciones aritméticas. El formato binario es adecuado para los mismos fines que
el formato decimal empaquetado, pero se utiliza con menos frecuencia.
8. Hay que incluir los formatos de entrada y salida mediante el uso de símbolos de codificación especiales para
indicar cómo se deben presentar los datos. En la figura 8.8 se muestran estos símbolos y sus usos. Cada
símbolo representa un carácter o dígito. Si se repite el mismo carácter varias veces, el carácter seguido de un
número entre paréntesis para indicar cuántas veces se repite el número se sustituye por el grupo. Por
ejemplo, XXXXXXXX se representaría como X(8).
9. Los criterios de validación para asegurar que el sistema capture datos precisos. Los elementos pueden ser
discretos para indicar que tienen ciertos valores fijos, o continuos con un rango uniforme de valores. He aquí
los criterios comunes de edición:
a. Un rango de valores es apropiado para los elementos que contienen datos continuos. Por ejemplo, en
Estados Unidos, un promedio de puntos de calificación para un estudiante puede ser del 0.00 al 4.00. Si
sólo hay un límite superior o inferior para los datos, se utiliza un límite en vez de un rango.
b. Se indica una lista de valores si los datos son discretos. Algunos ejemplos son los códigos que
representan los colores de los artículos que se venden en el catálogo de World’s Trend.
c. Una tabla de códigos es apropiada si la lista de valores es extensa (por ejemplo, abreviaciones de
estados, códigos telefónicos de países o códigos de área de teléfonos en los EE.UU.).
d. Para elementos clave o índice, a menudo se incluye un dígito de verificación.
10. Cualquier valor predeterminado que pueda tener el elemento. El valor predeterminado se muestra en las
pantallas de entrada y se utiliza para reducir la cantidad de información que tenga que teclear el operador.
Por lo general, varios campos en cada sistema tienen valores predeterminados. Cuando se emplean listas de
GUI o listas desplegables, el valor predeterminado es el que ya está seleccionado y resaltado. Al usar
botones de opción, está seleccionada la opción para el valor predeterminado, y al usar casillas de
verificación, el valor predeterminado (“sí” o “no”) determina si la casilla de verificación tendrá o no una
marca inicial en ella.
11. Un área adicional para comentarios. Ésta se podría usar para indicar el formato de la fecha, la validación
especial requerida, el método de dígito de verificación utilizado (lo cual explicaremos en el capítulo 15),
etcétera.
Tal vez las descripciones de los elementos de datos como NÚMERO DE CLIENTE se llamen NÚMERO DE
CONSUMIDOR en cualquier otra parte del sistema (es probable que debamos actualizar el código anterior es-
crito con este alias).
El elemento alfabético es otro tipo de elemento de datos. En la División de catálogos de World’s Trend, los
códigos se utilizan para describir colores: por ejemplo, BL para azul, WH para blanco y GR para verde. Al im-
plementar este elemento se necesitará una tabla para que los usuarios busquen los significados de estos códigos
(en el capítulo 15 hablaremos con más detalle sobre la codificación).
Almacenes de datos
Todos los elementos base deben estar guardados en el sistema. Los elementos derivados, como el sueldo bruto
del empleado del año a la fecha, también se pueden guardar en el sistema. Se crean almacenes de datos para cada
entidad de datos distinta que se piense guardar. Es decir, cuando se agrupan los elementos base del flujo de datos
para formar un registro estructural, se crea un almacén de datos para cada registro estructural único.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 237
Como tal vez un flujo de datos muestre sólo parte de los datos colectivos que contenga un registro estructu-
ral, tal vez tenga que examinar muchas estructuras de flujo de datos para obtener una descripción completa de un
almacén de datos.
La figura 8.9 es el formulario común que se utiliza para describir un almacén de datos. La información que
se incluye en el formulario es la siguiente:
1. El ID del almacén de datos. A menudo el ID es una entrada obligatoria para evitar que el analista guarde
información redundante. Un ejemplo sería D1 para el ARCHIVO MAESTRO DE CLIENTES.
2. El nombre del almacén de datos, que es descriptivo y único.
3. Un alias para la tabla, como ARCHIVO MAESTRO DE CONSUMIDORES para el ARCHIVO MAESTRO
DE CLIENTES.
4. Una descripción corta del almacén de datos.
5. El tipo de archivo, ya sea de computadora o manual.
6. El formato designa si el archivo es una tabla de base de datos o si tiene el formato de un simple archivo
plano (en el capítulo 13 describiremos con detalle los formatos de archivos).
7. El número máximo y promedio de registros en el archivo, así como el crecimiento por año. Esta información
ayuda al analista a predecir la cantidad de espacio en disco requerida para la aplicación; además es necesario
para planear la adquisición de hardware.
8. El nombre del archivo o conjunto de datos especifica el nombre del archivo, si se conoce. En las etapas de
diseño iniciales, podemos dejar este elemento en blanco. En la figura 8.10 se muestra un formulario
electrónico producido mediante el uso de Visible Analyst. Este ejemplo muestra que ARCHIVO MAESTRO
DE CLIENTES (CUSTOMER MASTER) se almacena en una computadora en la forma de una base de
Tipo de archivo Computadora Manual
Formato de archivo Base de datos Indexado Secuencial Directo
Tamaño del registro (caracteres): Tamaño de bloque:
Número de registros: Máximo Promedio:
Porcentaje de crecimiento anual: %
D 1
Archivo maestro de clientes
Archivo maestro de consumidores
Contiene un registro para cada cliente.
ID
Nombre
Alias
Descripción
Formulario de descripción de almacén de datos
Comentarios
Características del almacén de datos
200 4000
45,000 42,000
6
Nombre del conjunto de datos
Miembro de copia
Estructura de datos
Clave primaria
Claves secundarias
Cliente.MST
Clientmast
Registro de cliente
Número de cliente
Nombre del cliente
CP
Monto comprado del año a la fecha
Los registros del Archivo maestro de clientes se copian a un archivo
de clientes y también a un archivo de historial y se purgan si el cliente no ha comprado
un artículo en los últimos cinco años. Se puede retener un cliente, incluso aunque
no haya realizado una compra, con el hecho de solicitar un catálogo.
FIGURA 8.9
Un ejemplo de formulario de des-
cripción de almacén de datos de la
División de catálogos de World’s
Trend.www.xlibros.com

238 PARTE III • EL PROCESO DE ANÁLISIS
datos con un número máximo de 45,000 registros (en el capítulo 13 explicaremos los detalles sobre los
registros y las claves que se utilizan para ordenar la base de datos).
9. La estructura de datos debe usar un nombre que se encuentre en el diccionario de datos y que provea un
vínculo a los elementos para este almacén de datos. Como alternativa se podrían describir los elementos de
datos en el formulario de descripción del almacén de datos o en la pantalla de la herramienta CASE para el
almacén de datos. Las claves primaria y secundarias deben ser elementos (o una combinación de ellos) que
se encuentren en la estructura de datos. En el ejemplo, el NÚMERO DE CLIENTE es la clave primaria y
debe ser único. El NOMBRE DEL CLIENTE, CP y MONTO COMPRADO DEL AÑO A LA FECHA son
claves secundarias que se utilizan para registrar las secuencias en los informes y localizar registros en forma
directa (en el capítulo13 hablaremos sobre las claves). Los comentarios se utilizan para la información que
no se ajusta en ninguna de las categorías anteriores; pueden incluir cuestiones sobre la sincronización de la
actualización o los respaldos, seguridad u otro tipo de consideraciones.
CREACIÓN DEL DICCIONARIO DE DATOS
Las entradas en el diccionario de datos se pueden crear después de haber completado el diagrama de flujo de datos,
o construir a medida que éste se desarrolle. El uso de la notación algebraica y registros estructurales permite al ana-
lista desarrollar el diccionario de datos y los diagramas de flujo de datos mediante una metodología arriba-abajo. Por
ejemplo, el analista puede crear un flujo de datos Diagrama 0 después de las primeras entrevistas y al mismo tiempo
crear las entradas preliminares en el diccionario de datos. Por lo general estas entradas consisten en los nombres de
los flujos de datos que se encuentran en el diagrama de flujo de datos y sus correspondientes estructuras de datos.
Después de realizar varias entrevistas adicionales con los usuarios para aprender sobre los detalles del sistema
y las formas en que interactúan con él, el analista expandirá el diagrama de flujo de datos y creará los diagramas hi-
jos. Después hay que modificar el diccionario de datos para incluir los nuevos registros estructurales y los elemen-
tos que se hayan deducido de entrevistas posteriores, de la observación y del análisis de los documentos.
Cada nivel de un diagrama de flujo de datos debe usar datos apropiados. El Diagrama 0 debe incluir sólo formu-
larios, pantallas, informes y registros. A medida que se crean los diagramas hijos, el flujo de datos que entra y
sale de los procesos se vuelve cada vez más detallado, incluyendo los registros estructurales y los elementos.
La figura 8.11 muestra una porción de dos niveles del diagrama de flujo de datos y las correspondientes
entradas en el diccionario de datos para producir el cheque de nómina de un empleado. El proceso 5, que se
encuentra en el Diagrama 0, es una vista general de la producción de un CHEQUE DE NÓMINA DE EM-
PLEADO. La correspondiente entrada en el diccionario de datos para REGISTRO DE EMPLEADO muestra el
NÚMERO DE EMPLEADO y cuatro registros estructurales, la vista de los datos que se obtuvieron en las prime-
ras etapas del análisis. De manera similar, REGISTRO DE ARCHIVO DE TIEMPO y CHEQUE DE NÓMINA
DE EMPLEADO también se definen como una serie de estructuras.
FIGURA 8.10
Pantalla de Visible Analyst en la
que se muestra la descripción de
un almacén de datos.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 239
Es importante que los nombres de los flujos de datos en el diagrama de flujo de datos hijo estén contenidos
como elementos o registros estructurales en el flujo de datos del proceso padre. Volviendo al ejemplo, INFOR-
MACIÓN DE SALARIO (entrada en el proceso 5.3, CALCULAR MONTOS DE PAGO ACTUALES) es un
registro estructural contenido en el REGISTRO DE EMPLEADO (entrada para el proceso 5). De manera similar,
SUELDO BRUTO (salida del proceso 5.3.4, un proceso de nivel más bajo que no se muestra en la figura) está
contenido en el registro estructural MONTOS DE PAGO ACTUALES (salida del proceso padre 5.3, CALCU-
LAR MONTOS DE PAGO ACTUALES).
Análisis de la entrada y la salida
Un paso importante para crear el diccionario de datos es identificar y categorizar el flujo de datos de entrada y
salida del sistema. Los formularios de análisis de entrada y salida contienen los siguientes cambios que se inclu-
yen comúnmente:
1. Un nombre descriptivo para la entrada o salida. Si el flujo de datos está en un diagrama lógico, el nombre
debería identificar cuáles son los datos (por ejemplo, INFORMACIÓN DE CLIENTE). No obstante, si el
analista trabaja en el diseño físico o si el usuario declaró de manera explícita la naturaleza de la entrada o la
salida, el nombre debe incluir esa información relacionada con el formato. Algunos ejemplos son ESTADO
DE CUENTA DE FACTURACIÓN DE CLIENTE y CONSULTA DE DETALLES DE CLIENTE.
2. El contacto del usuario responsable de la aclaración de los detalles posteriores, la retroalimentación sobre el
diseño y la aprobación final.
3. Si los datos son de entrada o salida.
4. El formato del flujo de datos. En la etapa de diseño lógica, el formato puede estar indeterminado.
5. Los elementos que indican la secuencia de los datos en un informe o pantalla (tal vez en columnas).
6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o derivados, además de sus
criterios de edición.
Una vez completado el formulario, hay que analizar cada elemento para determinar si el elemento se repite,
si es opcional o si es mutuamente excluyente de otro elemento. Los elementos que caen en un grupo o que se
Estructura de datosFlujo de datos
Registro
de empleado
Número de empleado +
Información personal +
Información de salario +
Información de sueldo actual +
Información del año a la fecha
Registro
de archivo de
tiempo
Número de empleado +
Nombre de empleado +
Horas trabajadas
Cheque de
nómina
de empleado
Número de empleado +
Nombre de empleado +
Dirección +
Montos de pago actuales +
Cifras del año a la fecha
Información
de sueldo
Tasa de pago +
Número de dependientes
Montos
de pago
actuales
Sueldo bruto +
Retención federal +
Retención estatal +
Retención del seguro social +
Sueldo neto
Producir
cheque de
nómina
de empleado
5
Empleado
Registro de archivo
de tiempo
Cheque de
nómina
de empleado
Montos
de pago
actuales de
computadoras
5.3
Información
de salario
Horas
trabajadas
Montos de
pago actuales
=
=
=
=
=
Archivo de tiempo
de empleadosD2
D1 Archivo maestro
de empleados
Registro
de empleado
FIGURA 8.11
Dos diagramas de flujo de datos y sus correspondientes entradas en el diccionario
de datos para producir el sueldo de nómina de un empleado.www.xlibros.com

240 PARTE III • EL PROCESO DE ANÁLISIS
combinan con regularidad con otros elementos en muchas estructuras se deben colocar juntos en un registro es-
tructural.
Estas consideraciones se pueden ver en el Formulario de análisis de entrada y salida para la División de catá-
logos de World’s Trend (vea la figura 8.12). En este ejemplo de un ESTADO DE CUENTA DE FACTURACIÓN
O P O R T U N I D A D D E C O N S U L T O R Í A 8 . 1
¿Deseas triunfar en el teatro? ¡Mejora tu dicción(ario)!
M ientras usted entra a Merman’s, Annie Oaklea lo recibe cor-
dialmente y le dice: “Estoy encantada con el trabajo que hizo en los
diagramas de flujo de datos. Me gustaría que siguiera desempe-
ñando el rol de analista de sistemas en Merman’s para ver si puede
en un momento dado crear un sistema de información para nuestro
inventario de vestuarios. Por desgracia, algunos de los términos que
utiliza no se adaptan muy bien al lenguaje de Shakespeare. Sospe-
cho que es un ligero problema de traducción”.
Aferrado al elogio inicial de Annie, usted no se ve alterado por
su comentario final y llega a la determinación de que un diccionario
de datos basado en los diagramas de flujo de datos de las rentas y
devoluciones sería un gran éxito.
Empiece por escribir entradas para un sistema manual con el
mayor detalle posible. Prepare dos entradas de proceso de datos, dos
entradas de flujo de datos, dos entradas de almacén de datos, una en-
trada de estructura de datos y cuatro entradas de elementos de datos
mediante el uso de los formatos que vimos en este capítulo. Al repre-
sentar los elementos de datos interrelacionados con precisión recibirá
críticas muy favorables (vea la Oportunidad de consultoría 7.1).
Nombre de entrada/salida
Contacto de usuario
Tipo de archivo Salida Entrada
Formato de archivo Informe Pantalla Indeterminado
Elemento(s) de secuencia
Formulario de análisis de entrada y salida
Estado de cuenta de facturación del cliente
Susan Han
Código postal (secuencia de página)
Número de pedido
Nombre de elemento Longitud B/D Criterios de edición
Fecha actual 6 B (Suministrada por el sistema)
Número de cliente 6 D (incluye dígito de verificación)
Primer nombre del cliente 20 B Sin espacios
Apellido del cliente 15 B Sin espacios
Inicial segundo nombre del cliente 1 B A a la Z o Espacio
Calle 20 B Sin espacios
Departamento 20 B Sin espacios
Ciudad 20 B Sin espacios
Estado 2 B Abreviación de estado válida.
CP 9 B Numérico, últimas 4 opc.
Número de pedido 6 D > 0
Fecha del pedido 8 B MM/DD/AAAA
Total del pedido 9 D Formato: 9 (7)V99
Monto de pago anterior 5 D Formato: 9 (7)V99
Monto total deudor 9 D Formato; 9 (7)V99
Comentario 60 B
Comentarios Imprimir una página para cada cliente. Si hay más elementos de
los que puedan ajustarse en una página, continuar en una segunda página..
FIGURA 8.12
Un ejemplo de un formulario de
análisis de entrada/salida para la
División de catálogos de World’s
Trend.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 241
DEL CLIENTE, los elementos PRIMER NOMBRE DEL CLIENTE, APELLIDO DEL CLIENTE e INICIAL
SEGUNDO NOMBRE DEL CLIENTE se deben agrupar en un registro estructural.
Desarrollo de almacenes de datos
Otra actividad para crear el diccionario de datos es la de desarrollar almacenes de datos. Hasta ahora hemos
determinado qué datos necesitan fluir de un proceso a otro. Esta información se describe en las estructuras de
datos. Sin embargo, la información se puede almacenar en muchos lugares; además, en cada lugar se puede al-
macenar en forma distinta. Mientras que los flujos de datos representan datos en movimiento, los almacenes de
datos representan los datos estáticos.
Por ejemplo, cuando llega un pedido a World’s Trend (vea la figura 8.13) contiene en su mayor parte infor-
mación temporal; es decir, la información necesaria para llenar ese pedido específico, pero parte de esa informa-
ción se podría almacenar en forma permanente. Algunos ejemplos de esto podrían ser la información sobre los
clientes (para poderles enviar catálogos) y la información sobre los artículos (ya que estos artículos aparecerán
en los pedidos de muchos otros clientes).
Los almacenes de datos contienen información de una naturaleza permanente o semipermanente (temporal).
Los elementos NUMERO DE ARTÍCULO, DESCRIPCIÓN y COSTO DE ARTÍCULO son ejemplos de infor-
mación relativamente permanente, al igual que TASA DE IMPUESTO. Sin embargo, cuando se multiplica el
COSTO DEL ARTÍCULO por la TASA DE IMPUESTO, se calcula (o se deriva) el IMPUESTO A COBRAR.
Los valores derivados no tienen que guardarse en un almacén de datos.
Al crear almacenes de datos sólo para un informe o pantalla, los denominamos “vistas de usuario” ya que
representan la forma en que el usuario desea ver la información.
Archivo maestro
de clientes =
Número de cliente +
Nombre del cliente +
Dirección +
Teléfono +
Número de tarjeta de crédito corporativa +
Fecha de expiración
Archivo maestro
de artículos =
Número de artículo +
Precio +
Cantidad en existencia
Registro
de pedido =
Número de cliente +
Número de catálogo +
Fecha del pedido +
{Artículos del pedido disponibles} +
Total de mercancía +
(Impuestos) +
Envío y manejo +
Total del pedido +
Método de pago +
(Tipo de tarjeta de crédito) +
(Número de tarjeta de crédito) +
(Fecha de expiración)
Artículos del pedido
disponibles =
Número de artículo +
Cantidad ordenada +
Cantidad enviada +
Precio actual
Método de pago = [Cheque Crédito Giro postal]
Tipo de tarjeta
de crédito =
[World’s Trend American Express MasterCard Visa ]
FIGURA 8.13
Los almacenes de datos derivados
de un pedido pendiente en la
División de catálogos de World’s
Trend.www.xlibros.com

242 PARTE III • EL PROCESO DE ANÁLISIS
USO DEL DICCIONARIO DE DATOS
El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. A medida que el analista de sis-
temas aprende sobre los sistemas de la organización, se agregan elementos de datos al diccionario de datos. Por
otra parte, el diccionario de datos no es un fin en sí mismo y nunca deberá serlo. Para evitar desviarse con la
construcción de un diccionario de datos completo, el analista de sistemas debe considerarlo como una actividad
paralela al análisis y diseño de sistemas.
Para que tenga el máximo poder, el diccionario de datos debe enlazarse en varios programas de sistemas, de
manera que cuando se actualice o elimine un elemento del diccionario de datos, se actualice o elimine automáti-
camente de la base de datos. El diccionario de datos se convierte simplemente en una curiosidad histórica si no
se mantiene actualizado.
Podemos usar el diccionario de datos para crear pantallas, informes y formularios. Por ejemplo, examine la
estructura de datos para la LISTA DE SELECCIÓN DE PEDIDO de World’s Trend en la figura 8.14. Como se
han definido los elementos necesarios y sus longitudes, el proceso de crear documentos físicos consiste en orde-
nar los elementos de una forma agradable y funcional mediante el uso de los lineamientos de diseño y sentido
común. Los grupos repetitivos se convierten en columnas y los registros estructurales se agrupan en la pantalla,
el informe o el formulario. La distribución del informe para la LISTA DE SELECCIÓN DE PEDIDO de World’s
Trend se muestra en la figura 8.15. Cabe mencionar que PRIMER NOMBRE y APELLIDO PATERNO están
agrupados en NOMBRE; además CANTIDAD (SELECCIONADA y ORDENADA), SECCIÓN, NÚMERO DE
Lista de selección de pedido = Número de pedido +
Fecha del pedido +
Número de cliente +
Nombre del cliente +
Dirección del cliente +
Teléfono del cliente +
{Selección de artículos del pedido} +
Número de artículos
Selección de artículos del pedido = Número de artículo +
Descripción del artículo +
Descripción del tamaño +
Descripción del color +
Sección de almacén +
Número de repisa +
Cantidad ordenada +
Cantidad seleccionada
Nombre del cliente = Primer nombre +
(Inicial segundo nombre) +
Apellido paterno
Dirección = Calle +
(Departamento) +
Ciudad +
Estado +
CP +
(Expansión de CP) +
(País)
Teléfono Código de área +
Número local
FIGURA 8.14
Estructura de datos para una lista
de selección de pedido en la
División de catálogos de World’s
Trend.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 243
REPISA, NÚMERO DE ARTÍCULO, DESCRIPCIÓN DEL ARTÍCULO, TAMAÑO y COLOR forman una se-
rie de columnas, ya que son los elementos repetitivos.
La estructura de datos y los elementos para un almacén de datos se utilizan comúnmente para generar el
correspondiente código fuente en lenguaje de computadora, el cual se incorpora a su vez en los programas de
computadora. Podemos utilizar el diccionario de datos junto con el diagrama de flujo de datos para analizar el
diseño del sistema, detectar fallas y áreas que necesiten aclaración. Algunas consideraciones son:
1. Todos los elementos base en un flujo de datos de salida deben estar presentes en un flujo de datos de entrada
para el proceso que produce la salida. Los elementos base se teclean; nunca deben ser creados por un proceso.
2. Un elemento derivado debe ser creado por un proceso y debe estar en la salida de por lo menos un proceso
del cual no sea entrada.
3. Los elementos presentes en un flujo de datos entrante o saliente de un almacén de datos deben estar
contenidos en el almacén de datos.
Si se empieza en las primeras etapas de las fases de análisis y diseño, el diccionario de datos nos puede ahorrar
muchas horas. Éste es la única fuente común en la organización para responder preguntas y resolver disputas sobre
cualquier aspecto de la definición de datos. Un diccionario de datos actualizado puede constituir un excelente marco
de referencia para los esfuerzos de mantenimiento en sistemas con los que no estemos familiarizados. Los dicciona-
rios de datos automatizados pueden servir como referencias tanto para las personas como para los programas.
Uso de diccionarios de datos para crear XML
El lenguaje de marcado extensible (XML) es un lenguaje que se puede usar para intercambiar datos entre las
empresas o entre los sistemas dentro de una empresa. Es similar al HTML, el lenguaje de marcado que se uti-
liza para crear páginas Web, sólo que es más potente. El HTML se enfoca principalmente en el formato de un
documento; XML aborda el problema de compartir los datos cuando los usuarios tienen distintos sistemas compu-
Número de pedido: 999999 Fecha del pedido Z9/99/9999
Número de cliente: 999999
Nombre: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Calle: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
Departamento: XXXXXXXX
Ciudad, estado, CP XXXXXXXXXXXXXXXXXXXXXXXXXXXX, XX 99999-ZZZZ
País: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
Teléfono: (999) 999-9999
Lista de selección de pedido
---- Cantidad ---- Número
de repisa
Número
de artículoSeleccionada Ordenada Sección Descripción del artículo Tamaño Color
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
ZZZZ9 XXXXX 99999 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXX
Número de artículos: Z9
World’s Trend
FIGURA 8.15
Lista de selección de pedido creada a
partir del diccionario de datos.www.xlibros.com

244 PARTE III • EL PROCESO DE ANÁLISIS
tacionales y distinto software, o distintos sistemas de administración de bases de datos (por ejemplo, cuando una
empresa utiliza Oracle y otra utiliza DB2 de IBM). Si todos usaran el mismo software o sistema de administra-
ción de bases de datos, el XML se utilizaría muy poco.
Una vez creado un documento de XML, podemos transformar los datos en varios formatos de salida, para
visualizarlos en muchas formas, incluyendo la salida impresa, páginas Web, la salida para un dispositivo portátil
y archivos de formato de documento portable (PDF). Por ende, el contenido de datos del documento se separa
del formato de salida. El contenido de XML se define una vez como datos y después se transforma todas las ve-
ces que sea necesario.
La ventaja de usar un documento de XML es que el analista puede seleccionar sólo los datos que necesitan
un departamento interno o un socio interno para poder funcionar. Esto ayuda a asegurar la confidencialidad de
los datos. Por ejemplo, una empresa de embarques puede recibir sólo el nombre del cliente, la dirección, el nú-
mero de artículo y la cantidad a enviar, pero no la información sobre la tarjeta de crédito u otros datos financie-
ros. Este eficiente método también reduce la sobrecarga de información.
Por lo tanto, el XML es una forma de definir, ordenar, filtrar y traducir datos en un lenguaje de datos univer-
sal que todos puedan utilizar. El XML se puede crear a partir de bases de datos, un formulario o programas de
software, o se puede teclear directamente en un documento, editor de texto o programa para introducir XML.
El diccionario de datos es un punto de inicio ideal para desarrollar contenido de XML. La clave para usar el
XML es crear una definición estándar de los datos. Para lograr esto hay que usar un conjunto de etiquetas o nom-
bres de datos que se incluyan antes y después de cada elemento o estructura de datos. Las etiquetas se convierten
en los metadatos, o datos sobre los datos. Éstos se pueden seguir dividiendo en elementos y estructuras de menor
tamaño hasta que se definan todos los elementos. Los elementos de XML también pueden incluir atributos: una
pieza de datos adicional que se incluye con la etiqueta y describe algo sobre el elemento de XML.
La figura 8.16 muestra un diccionario de datos que contiene información sobre cliente, pedido y pago. La
colección general de clientes se incluye en lo que se denomina elemento raíz: clientes. Un documento de XML
puede contener sólo un elemento raíz, por lo que a menudo es el plural de los datos contenidos en el documento
de XML. Cada cliente puede colocar muchos pedidos. La estructura se define en las dos columnas izquierdas
y el código de XML aparece a la derecha. Como puede ver, CLIENTE consiste en NOMBRE, DIRECCIÓN,
SALDO ACTUAL, varias entradas INFORMACIÓN DE PEDIDO y un PAGO. Algunas de estas estructuras se
subdividen todavía más.
El documento de XML tiende a reflejar la estructura del diccionario de datos. La primera entrada (además de
la línea de XML que identifica el documento) es <cliente>, la cual define la colección completa de información
del cliente. Los símbolos menor que (<) y mayor que (>) se utilizan para identificar los nombres de las etiquetas
(en forma similar al HTML). La última línea del documento de XML es una etiqueta de cierre, </cliente>, que in-
dica el final de la información del cliente.
El cliente se define primero y contiene un atributo, el número de cliente. A menudo hay un debate en cuanto
a si debemos almacenar los datos como un elemento o un atributo. En este caso se almacenan como atributo.
La etiqueta de nombre <nombre> se define a continuación, ya que es la primera entrada en el diccionario de
datos. NOMBRE es una estructura que consiste en APELLIDO PATERNO, PRIMER NOMBRE y una INICIAL
DE SEGUNDO NOMBRE opcional. En el documento de XML esta estructura empieza con <nombre> y va se-
guida de <apellidopaterno>, <primernombre> y <inicialsegundonombre>. Como no se permiten espacios en los
nombres de las etiquetas de XML, por lo general se utiliza un guión bajo para separar las palabras. La etiqueta de
cierre </nombre> indica el final del grupo de elementos. Al utilizar una estructura como nombre podemos ahorrar
tiempo y código si la transformación muestra el nombre completo. Cada uno de los elementos hijos estará en una
línea separada por un espacio. El nombre también contiene un atributo, ya sea I de individuo o C de corporación.
Se utiliza la sangría para mostrar qué estructuras contienen elementos. Cabe mencionar que <direccion> es
similar a <cliente>, pero cuando llegamos a <informacion_pedido> hay una gran diferencia.
Hay varias entradas para <informacion_pedido>, cada una de las cuales contiene un <numero_pedido>, <fe-
cha_pedido>, <fecha_envio> y <total>. Como el pago se hace por cheque o tarjeta de crédito, puede haber sólo
una de estas dos opciones presentes. En nuestro ejemplo, el pago se hace por cheque. Las fechas tienen un atri-
buto conocido como formato, el cual indica si la fecha aparece como mes, día año; como año, mes, día; o como
día, mes, año. Si se utiliza una tarjeta de crédito para hacer un pago, un atributo TIPO contiene una M, V, A, D, o
una O para indicar el tipo de tarjeta de crédito (MasterCard, Visa u otro tipo).
Definiciones de tipo de documento de XML
A menudo la estructura del contenido de XML se define mediante el uso de una definición de tipo de documento
(DTD). Esta definición se utiliza para determinar si el contenido del documento de XML es válido; es decir, si
cumple con el orden y tipo de los datos que deben estar presentes en el documento. Es fácil crear la DTD y ade-
más cuenta con muy buen soporte a través de software estándar. Una vez completada la DTD, podemos usarla
para validar el documento de XML mediante el uso de las herramientas estándar de XML. Es más fácil crear lawww.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 245
DTD si se ha completado un diccionario de datos, ya que significa que el analista trabajó con los usuarios y tomó
decisiones en cuanto a la estructura de los datos.
La figura 8.17 ilustra la definición de tipo de documento para el documento de XML llamado Cliente. Las
palabras clave tales como !DOCTYPE, que indica el inicio de la DTD, deben estar todas en mayúsculas. !ELE-
MENT describe un elemento y !ATTLIST describe un atributo; se enlista el nombre del elemento seguido por el
nombre del atributo. Un elemento con la palabra clave #PCDATA (Parsed Character Data, o datos tipo carácter
analizados) es un elemento primitivo que ya no se define con más detalle. Un elemento que tiene una serie de
otros elementos entre paréntesis indica que son elementos hijos y deben estar en el orden listado. La instrucción
<!ELEMENT nombre (apellidopaterno, primernombre, inicial_segundonombre?)> indica que el nombre debe
tener el apellido paterno, seguido del primer nombre, seguido de la inicial del segundo nombre. El signo de
Diccionario de datos XML
<?xml version="1.0">
<clientes>
<cliente numero="C15008">
<nombre tipo="I">
<apellidopaterno>Stadler</apellidopaterno>
<primernombre>Karen</primernombre>
<inicial_segundonombre>L</inicial_segundonombre>
</nombre>
<direccion>
<calle>123 Oak Street</calle>
<departamento>Suite 16</departamento>
<ciudad>Madison</ciudad>
<estado>WI</estado>
<cp>43704</cp>
<pais>Estados Unidos</pais>
</direccion>
<saldo_actual>123.45</saldo_actual>
<pedido numero_cliente="C15008">
<numero_pedido>00123</numero_pedido>
<fecha_pedido formato="aaaammdd">2008-06-23</fecha_pedido>
<fecha_envio formato="aaaammdd">2008-06-25</fecha_pedido>
<total>1345.89</total>
</pedido>
<pedido numero_cliente="C15008">
<numero_pedido>00127</numero_pedido>
<fecha_pedido formato="aaaammdd">2008-09-18</fecha_pedido>
<fecha_envio formato="aaaammdd">2008-09-26</fecha_pedido>
<total>240.00</total>
</pedido>
<pago>
<cheque>
<numero_cheque>7234</numero_cheque>
</cheque>
<fecha_pago formato="aaaammdd">2008-09-30</fecha_pago>
<monto_pago>1585.89</monto_pago>
<pago>
<cliente>
</clientes>
Cliente = Nombre +
Dirección +
Saldo actual +
{Información de pedido} +
Pago
Apellido paterno +
Primer nombre +
(Inicial segundo nombre)
Nombre =
Calle +
(Departamento) +
Ciudad +
Estado +
CP +
País
Dirección =
Número de pedido +
Fecha de pedido +
Fecha de envío +
Total
Información
de pedido =
Pago =
Número de chequeCheque =
Número de tarjeta de crédito +
Fecha de expiración
Tarjeta de crédito =
[Cheque Tarjeta de crédito] +
Fecha de pago +
Monto de pago
FIGURA 8.16
Uso de una entrada en el diccionario de datos para desarrollar contenido de XML. El
documento de XML refleja la estructura del diccionario de datos.www.xlibros.com

246 PARTE III • EL PROCESO DE ANÁLISIS
interrogación después de “inicial_segundonombre” significa que el elemento es opcional y se puede omitir del
documento para un cliente específico. Un signo positivo indica que hay uno o más elementos que se pueden
repetir. Los clientes deben contener por lo menos una etiqueta de cliente, pero pueden contener muchas de estas
etiquetas. Un asterisco significa que hay cero o más de los elementos. Cada cliente puede tener cero o más pe-
didos. Una barra vertical separa dos o más elementos hijos que son mutuamente excluyentes. El pago contiene
ya sea cheque o tarjeta de crédito como opción.
La definición de la lista de atributos para un número de cliente contiene un ID de palabra clave (en letras ma-
yúsculas). Esto significa que el atributo número debe aparecer sólo una vez en el documento de XML como atri-
buto para un elemento con un ID. Esto es algo similar a una clave primaria; la diferencia es que, si el documento
tuviera distintos elementos, cada uno con un atributo ID, el ID dado (C15008 en este ejemplo) podría aparecer
sólo una vez. Un ID debe empezar con una letra o guión bajo y no puede ser únicamente un número. La razón
para poner el número de cliente como ID es para asegurar que no se repita en un documento más extenso. La pala-
bra clave #REQUIRED significa que el atributo debe estar presente. La palabra clave #IMPLIED significa que el
atributo es opcional. Un documento también puede tener un atributo IDREF, el cual vincula un elemento con otro
que sea ID. La etiqueta PEDIDO tiene un atributo numero_cliente definido como IDREF y el valor C15008 debe
estar presente en un ID en alguna parte del documento. Una lista de atributos que contenga valores entre parénte-
sis significa que el atributo debe contener uno de los valores. La definición de DTD <!ATTLIST tarjeta_credito
tipo (M|V|A|D|O) #REQUIRED> significa que el tipo de tarjeta de crédito debe ser M, V, A, D u O.
Esquemas de XML
Un esquema es otra manera más precisa de definir el contenido de un documento de XML. Los esquemas pueden
incluir el número exacto de veces que puede ocurrir un elemento, así como el tipo de datos dentro de los elemen-
< !DOCTYPE clientes [
< !ELEMENT clientes
< !ELEMENT cliente
< !ATTLIST cliente numero
< !ELEMENT nombre
< !ATTLIST nombre tipo
<!ELEMENT apellidopaterno
< !ELEMENT primernombre
< !ELEMENT inicial_segundonombre
< !ELEMENT direccion
< !ELEMENT calle
< !ELEMENT departamento
< !ELEMENT ciudad
< !ELEMENT estado
< !ELEMENT cp
< !ELEMENT pais
< !ELEMENT saldo_actual
< !ELEMENT pedido
< !ATTLIST pedido numero_cliente
< !ELEMENT numero_pedido
< !ELEMENT fecha_pedido
< !ATTLIST fecha_pedido formato
< !ELEMENT pago
< !ELEMENT cheque
< !ELEMENT tarjeta_credito
< !ATTLIST tarjeta_credito tipo
< !ELEMENT numero_tarjeta_credito
< !ELEMENT fecha_expiracion
< !ELEMENT fecha_pago
< !ATTLIST fecha_pago formato
< !ELEMENT monto_pago
]>
(cliente)+>
(nombre, direccion, saldo_actual, pedido*)>
ID #REQUIRED>
(apellidopaterno, primernombre, inicial_segundonombre?>
(I/C #REQUIRED>
(#PCDATA) >
#PCDATA) >
(#PCDATA) >
(calle, departamento?, ciudad, cp, país)>
(#PCDATA) >
(#PCDATA) >
(#PCDATA) >
(#PCDATA) >
(#PCDATA) >
(#PCDATA) >
(#PCDATA) >
(numero_pedido, fecha_pedido, fecha_envio, total)>
IDREF #REQUIRED>
(#PCDATA) >
(#PCDATA) >
(mmddaaaa|aaaammdd|ddmmaaaa) #REQUIRED>
(cheque|tarjeta_credito >
(numero_cheque)>
(numero_tarjeta_credito, fecha_expiracion)>
(M|V|A|D|O #REQUIRED>
(#PCDATA) >
(#PCDATA) >
(#PCDATA) >
(mmddaaaa|aaaammdd|ddmmaaaa) #REQUIRED>
(#PCDATA) >
FIGURA 8.17
Una definición de tipo de
documento para el documento
de XML cliente.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 247
EXPERIENCIA DE HYPERCASE® 8
“En realidad lo está haciendo muy bien. Snowden dice que us-
ted le ha dado todo tipo de nuevas ideas para dirigir el nuevo depar-
tamento. Eso es decir bastante, si consideramos que él tiene muchas
ideas propias. Para este momento espero que haya tenido la oportu-
nidad de hablar con todos los que usted quería: en definitiva con
Snowden, Toni Ketcham, Daniel Hill y el Sr. Hyatt”.
“El Sr. Hyatt es un alma escurridiza, ¿verdad? Creo que yo no
lo conocí sino hasta mi tercer año. Espero que usted pueda averiguar
sobre él en mucho menos tiempo. Oh, pero cuando lo llega uno a
conocer es todo un personaje, ¿o no? Y esos locos aeroplanos. Casi
se estrella uno en mi cabeza en el estacionamiento. Pero ¿cómo se
puede uno enojar si es El Jefe quien lo está volando? También tiene un
jardín oriental secreto (o debería decir privado) afuera de su suite de
oficina. No, nunca lo podrá ver en los planes de construcción. Tiene
que llegar a conocerlo muy bien antes de que él le muestre eso, pero
apostaría a que es el único en su género en Tennessee y tal vez en todo
Estados Unidos. Se enamoró de los maravillosos jardines que vio en
el sureste de Asia cuando era joven. Sin embargo, es algo que va más
allá de eso. El Sr. Hyatt sabe el valor de la contemplación y la medi-
tación. Si él tiene una opinión, usted puede estar seguro de que la ha
considerado mucho”.
Preguntas de HYPERCASE
1. Haga una breve lista de los elementos de datos que haya
encontrado en tres distintos informes producidos en MRE.
2. Con base en sus entrevistas con Snowden Evans y los demás,
haga una lista de los elementos de datos que crea usted que
deba agregar a los sistemas de informes del proyecto de la
Unidad de capacitación para capturar mejor los datos
importantes sobre el estado del proyecto, los tiempos de
entrega y las estimaciones de presupuesto.
3. Cree una entrada en el diccionario de datos para un nuevo
almacén de datos, un nuevo flujo de datos y un nuevo
proceso de datos que usted sugiera con base en su respuesta a
la pregunta 2.
4. Sugiera una lista de nuevos elementos de datos que podrían
ser útiles para Jimmy Hyatt, pero que en definitiva no estén
disponibles para él en la actualidad.
FIGURA 8.HC1
En HyperCase podemos ver el
diccionario de datos que se
mantiene en MRE.
tos, como los valores tipo carácter o numérico, incluyendo la longitud del elemento, los límites sobre los datos y
el número de lugares a la izquierda y derecha de un número decimal.
Un diccionario de datos es un excelente punto de partida para desarrollar un documento de XML y un tipo
de documento de definición o esquema. La ventaja de usar XML para definir datos es que, en el formato de
XML, los datos se almacenan en texto puro y no dependen de ningún software propietario. El documento se
puede validar y transformar fácilmente en muchos formatos distintos de salida.
Los grupos u organizaciones industriales pueden estar involucrados en la definición de una estructura de
XML específica de la industria, de manera que todas las partes involucradas comprendan lo que significan los
datos. Esto es muy importante cuando el nombre de un elemento puede tener distintos significados. Un ejemplowww.xlibros.com

248 PARTE III • EL PROCESO DE ANÁLISIS
PALABRAS CLAVE Y FRASES
decimal empaquetado
decimal por zonas
definición de tipo de documento (DTD)
diccionario de datos
elemento base
elemento de datos
elemento derivado
elemento repetitivo
entregables del sistema
esquema
estructura de datos
estructura física de datos
formato binario
grupo repetitivo
ID
IDREF
lenguaje de marcado extensible (XML)
registro estructural
repositorio
varchar
PREGUNTAS DE REPASO
1. Defina diccionario de datos y metadatos.
2. ¿Cuáles son las cuatro razones para compilar un diccionario de datos completo?
3. ¿Qué información está contenida en el repositorio de datos?
4. ¿Qué es un registro estructural?
5. Haga una lista de las ocho categorías específicas que debe contener cada entrada en el diccionario de datos. Mencione
una definición breve de cada categoría.
6. ¿Cuáles son las diferencias básicas entre las entradas en el diccionario de datos preparadas para los almacenes de datos,
las estructuras de datos y los elementos de datos?
7. ¿Por qué se utilizan registros estructurales?
8. ¿Cuál es la diferencia entre estructuras de datos lógicas y físicas?
9. Describa la diferencia entre elementos base y derivados.
10. ¿Cómo se relacionan las entradas en el diccionario de datos con los niveles en un conjunto de diagramas de flujo de
datos?
11. Haga una lista de los cuatro pasos que se deben llevar a cabo para compilar un diccionario de datos.
12. ¿Por qué la compilación del diccionario de datos no se debe ver como un final en sí?
13. ¿Cuáles son los principales beneficios de usar un diccionario de datos?
14. ¿Qué describe el lenguaje de marcado extensible (XML)?
15. ¿Qué es una definición de tipo de documento?
16. ¿Cómo ayuda una definición de tipo de documento a asegurar que un documento de XML contenga todos los elementos
necesarios?
17. ¿Cuándo se deben usar atributos en un documento de XML?
18. ¿Qué asegura un atributo ID?
19. ¿Qué valida un atributo IDREF?
es “estado”, el cual puede significar la abreviación de un estado postal, o el estado de un pedido o cuenta. En el
sitio Web www.xml.org encontrará ejemplos de definiciones de tipo de documento y esquemas de XML.
Mediante el uso de una metodología arriba-abajo, el analista de
sistemas utiliza los diagramas de flujo de datos para empezar a
compilar un diccionario de datos, una obra de consulta que con-
tiene datos sobre los datos, o metadatos, de todos los procesos,
almacenes, flujos y estructuras de datos, además de todos los
elementos lógicos y físicos del sistema que se está estudiando.
Una manera de empezar es incluir todos los elementos de datos
de los diagramas de flujo de datos.
Un repositorio es una colección más grande de información
sobre el proyecto. Las herramientas CASE permiten al analista
crear un repositorio que pueda incluir información sobre flujos
de datos, almacenes, estructuras de registros y elementos; sobre
el diseño de pantallas e informes de la lógica de procedimiento;
y sobre las relaciones de los datos. Un repositorio también puede
contener información sobre los requerimientos de los proyectos
y los entregables finales del sistema; además de la información
administrativa del proyecto.
Cada entrada en el diccionario de datos contiene el nombre del
elemento, una descripción en español, los alias, los elementos de
datos relacionados, el rango, la longitud, la codificación y la infor-
mación de edición necesaria. El diccionario de datos es útil en todas
las fases de análisis, diseño y en última instancia, de documenta-
ción, ya que es la fuente de autoridad que describe cómo se usa un
elemento de datos y cómo lo definen los usuarios en el sistema.
Muchos sistemas grandes incluyen diccionarios de datos compu-
tarizados que realizan referencias cruzadas en todos los programas
en la base de datos que utilizan un elemento de datos específico. El
diccionario de datos también se puede usar para crear XML que
permita a las empresas con distintos sistemas, software o sistemas
de administración de bases de datos, intercambiar información.
RESUMENwww.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 249
PROBLEMAS
1. Con base en la figura 7.EJ1 del capítulo 7, Joe, uno de los miembros de su equipo de análisis de sistemas, hizo la
siguiente entrada en el diccionario de datos que utiliza Marilyn’s Tours:
ELEMENTO DE DATOS = TURISTA* * * * PAGO
ALIAS = PAGO TURISTA
CARACTERES = 12-24
RANGO = $5.00-$1,000
VARIABLES = $5.00, $10.00, $15.00 hasta $1,000, y cualquier cosa entre ese rango en dólares y centavos.
PARA CALCULAR = COSTO TOTAL DE TODOS LOS PASEOS, CUALQUIER IMPUESTO APLICABLE DEL
ESTADO DE N.Y., menos los DEPÓSITOS DE RESERVACIÓN realizados.
a. ¿Es éste un verdadero elemento de datos? ¿Por qué sí o por qué no?
b. Vuelva a escribir la entrada en el diccionario de datos para PAGO DE TURISTA y reclasifíquela si es necesario. Use
la forma apropiada para la clasificación que elija.
2. Sue Kong, la analista de sistemas, ha realizado un progreso considerable para comprender el movimiento de datos en
Shanghai Megabank. Para compartir lo que ha hecho con los demás miembros de su equipo, así como con el jefe de
operaciones regionales, está formando un diccionario de datos.
a. Escriba una entrada en el diccionario de datos de Sue para tres de los flujos de datos en la banca regional. La entrada
deberá estar lo más completa que sea posible.
b. Escriba una entrada en el diccionario de datos de Sue para tres de los almacenes de datos en la banca regional. La
entrada deberá estar lo más completa que sea posible.
3. Jorge Alvarez, el gerente de la librería con la que su equipo de análisis de sistemas ha estado trabajando para crear un
sistema de inventario computarizado, siente que uno de los miembros de su equipo está convirtiéndose en una verdadera
molestia al hacerle preguntas en extremo detalladas sobre los elementos de datos utilizados en el sistema. Por ejemplo,
pregunta: “Jorge, ¿cuánto espacio, en caracteres, ocupa el listado de un ISBN?”.
a. ¿Cuáles son los problemas que se crean al ir directamente con el gerente y hacerle preguntas relacionadas con las
entradas en el diccionario de datos? Use un párrafo para listar los problemas que pueda ver con el método del
miembro de su equipo.
b. Explique en un párrafo al miembro de su equipo cómo puede obtener información de una mejor manera para el
diccionario de datos.
4. Michael Bush es propietario de una tienda especializada en ropa y accesorios de viaje. Los fabricantes tienen su propia
codificación, pero hay muchos fabricantes. Establezca elementos de datos para seis distintos sombreros de viaje de tres
distintos proveedores.
5. Michael (del problema 4) también ensambla paquetes de kits para acampar. Cada kit es un grupo de cuatro productos
separados que se venden en un paquete. Cada paquete (conocido como PRODUCTO) se construye mediante el uso de
muchas piezas, las cuales varían de un producto a otro. A través de las entrevistas con el jefe de piezas se obtuvo una
lista de elementos para la página Web PIEZAS DE PRODUCTO, la cual muestra qué piezas se utilizan en la fabricación
de cada producto. En la figura 8.EJ1 se muestra un prototipo de la página Web PRODUCTO-PIEZA (PRODUCT-
PART). Cree una entrada de estructura de datos en el diccionario para PRODUCTO-PIEZA.
FIGURA 8.EJ1
Un prototipo de la página Web
PRODUCTO-PIEZA (PRODUCT-
PART).www.xlibros.com

250 PARTE III • EL PROCESO DE ANÁLISIS
9. Haga una lista de los archivos maestros que serían necesarios para implementar la CONSULTA DE DISPONIBILIDAD
DE CRUCERO.
10. Los siguientes puertos de parada están disponibles para la empresa Pacific Holiday Company:
Cree el elemento PUERTO DE PARADA. Examine los datos para determinar la longitud y el formato del elemento.
6. Analice los elementos encontrados en la página Web PRODUCTO-PIEZA y cree la estructura de datos para los
almacenes de datos ARCHIVO MAESTRO DE PRODUCTO y ARCHIVO MAESTRO DE PIEZA.
7. ¿Cuáles de los elementos en la página Web PRODUCTO-PIEZA son elementos derivados?
8. La empresa Pacific Holiday Company hace los arreglos para las vacaciones en crucero de duraciones variables en
diversas ubicaciones. Cuando los clientes llaman para verificar la disponibilidad de un crucero se utiliza una
CONSULTA DE DISPONIBILIDAD DE CRUCERO, la cual se muestra en la página 8.EJ2, para proveerles la
información. Cree la estructura del diccionario de datos para la CONSULTA DE DISPONIBILIDAD DE CRUCERO.
MM/DD/AAAA DISPONIBILIDAD DE CRUCERO HH:MM
INTRODUZCA FECHA INICIAL Z9-ZZZ-9999
INFORMACIÓN DE CRUCERO
BARCO CRUCERO XXXXXXXXXXXXXXXXXXX
UBICACIÓN XXXXXXXXXXXXXXXXXXX
FECHA DE INICIO Z9-ZZ Z-9999 FECHA DE TERMINACIÓN Z9-ZZZ-9999
NÚMERO DE DÍAS Z Z 9
COSTO ZZ ,ZZZ.99
DESCUENTOS ACEPTADOS XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXXX
VACANTES DISPONIBLES ZZ ZZ9
FIGURA 8.EJ2
Una pantalla que muestra la
disponibilidad de un crucero.
11. Raúl Esparza, gerente de comercio electrónico de Moonlight Mugs, una empresa que vende tazas de café personalizadas,
desea enviar información a otra empresa que mantiene el almacén y provee servicios de envío. La información de los
pedidos se obtiene a través de un sitio Web seguro, incluyendo el número de cliente, nombre y dirección, número
telefónico, dirección de correo electrónico, número y cantidad de producto, así como la información de la tarjeta de
crédito. Puede haber distintos productos que se envíen en un pedido. La empresa de envío maneja artículos para otros
negocios pequeños también. Defina un documento de XML que incluya sólo la información que necesite la empresa de
envío para enviar los artículos al cliente.
12. Una vez enviado el pedido del problema 11, la empresa de envío devuelve la información a Moonlight Mugs, incluyendo
el nombre y la dirección del cliente, el número de rastreo del envío, los datos enviados, la cantidad ordenada, la cantidad
enviada y la cantidad pendiente. Defina un documento de XML que incluya la información que se envía a Moonlight
Mugs.
13. Cree una definición de tipo de documento para el problema 11.
14. Western Animal Rescue es una organización sin fines de lucro que brinda apoyo para la adopción temporal y permanente
de animales, como gatos, perros y aves. Las personas se pueden registrar para adoptar animales. Otros se registran y
agregan animales para adopción. Cree la estructura de diccionario de datos que represente a una persona que se registre
Apia Nuku Hiva Auckland
Pago Pago Papeete Wellington
Bora Bora Raiatea Christ Church
Moorea Napier Dunedinwww.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 251
para adoptar un animal. Incluya el nombre, la dirección (calle, ciudad, estado o provincia, código postal o código de correo),
número telefónico, dirección de correo electrónico, fecha de nacimiento, mascotas actuales (tipo, raza, edad de la
mascota) y referencias. Cada persona puede tener varias mascotas y debe tener por lo menos tres referencias. Éstas
deben incluir el nombre, la dirección, número telefónico, dirección de correo electrónico y cómo conocen a la persona
que se registró para adoptar un animal. Asegúrese de incluir la notación para los elementos repetitivos y los elementos
opcionales.
15. Defina la longitud, el tipo de datos y los criterios de validación para cada uno de los elementos del problema 14.
16. Haga una lista de los almacenes de datos que se requerirían para implementar a la persona que se registra en el problema 14.
17. Cree un documento de XML con datos de muestra para una persona que se registre para adoptar a un animal.
PROYECTOS EN GRUPO
1. Reúnase con su grupo y use una herramienta CASE o un procedimiento manual para desarrollar entradas en el
diccionario de datos para un proceso, flujo de datos, almacén de datos y estructura de datos con base en los diagramas de
flujo que completó para Maverick Transport en los ejercicios en grupo del capítulo 7. Como grupo, lleguen a un acuerdo
en cuanto a las suposiciones necesarias para realizar entradas completas para cada elemento de datos.
2. Su grupo deberá desarrollar una lista de métodos para ayudarle a realizar entradas completas en el diccionario de datos
para este ejercicio, así como para futuros proyectos. Por ejemplo, estudiar los informes existentes, basarse en diagramas
de flujo de datos nuevos o existentes, etcétera.
BIBLIOGRAFÍA SELECCIONADA
Baskerville, R. y J. Pries-Heje. “Short Cycle Time Systems Development”. Information Systems Journal, Vol. 14, 2004, pp.
237-264.
Conboy, K. y B. Fitzgerald. “Toward a Conceptual Framework of Agile Methods: A Study of Agility in Different Disciplines”,
WISER ’04, 5 de noviembre de 2004, Newport Beach, CA, pp. 37-44.
Davis, G. B. y M. H. Olson. Management Information Systems, Conceptual Foundations, Structure, and Development, 2ª. Edi-
ción. Nueva York: McGraw-Hill, 1985.
Gane, C. y T. Sarson. Structured Systems Analysis and Design Tools and Techniques. Englewood Cliffs, NJ: Prentice Hall,
1979.
Hoffer, J. A., M. Prescott y H. Topi. Modern Database Management, 9ª. Edición. Upper Saddle River, NJ: Prentice Hall,
2009.
Lucas, H. Information Systems Concepts for Management, 3ª. Edición. Nueva York: McGraw-Hill, 1986.
Martin, J. Strategic Data-Planning Methodologies. Englewood Cliffs, NJ: Prentice Hall, 1982.
Sagheb-Tehrani, M. “Expert Systems Development and Some Ideas of Design Process”. ACM SIGSOFT Software Engineering
Notes, Vol. 30, Núm. 2, marzo de 2005, pp. 1-5.
Schmidt, A. Working with Visible Analyst Workbench for Windows. Upper Saddle River, NJ: Prentice Hall, 1996.
Subramaniam, V. y A. Hunt. Practices of an Agile Developer. Raleigh, NC: Pragmatic Bookshelf, 2006.www.xlibros.com

252 PARTE III • EL PROCESO DE ANÁLISIS
E P I S O D I O 8
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Definir lo que queremos decir
“Podemos usar los diagramas de flujo de datos que completamos para crear entradas en el diccionario de datos para todos los
flujos de datos y almacenes de datos”, dice Chip a Anna en su siguiente reunión. Cada uno de estos componentes tiene una
entrada de composición en el repositorio. Por ende, los registros que se crean para el sistema computacional están vinculados a
los componentes del diagrama de flujo de datos que describen los datos.
Anna y Chip se reúnen para dividir el trabajo de crear registros y elementos. “Voy a desarrollar el diccionario de datos para
la parte del sistema relacionada con el software”, dice Anna.
“Por suerte me gusta hacerme cargo del hardware”, bromea Kid en forma amigable.
Primero se crean los registros, o estructuras de datos. Éstos pueden contener elementos, los bloques básicos de construcción
de la estructura de datos, y también pueden contener otros registros en ellos, conocidos como registros estructurales. Visible
Analyst también mantiene las relaciones entre los componentes de los diagramas, los registros y los elementos que se pueden
usar para análisis e informes. Como Microsoft Visio no tiene un repositorio para los objetos de los diagramas de flujo de datos,
utilizaremos el repositorio de Visible Analyst para ilustrar el repositorio en este episodio.
Mediante el uso de la información de las entrevistas y las pantallas del prototipo, Anna empieza a crear los registros de
software. Como la salida de un sistema determina lo que se necesita para almacenar y obtener los datos por medio de pantallas
de entrada de datos, el punto de inicio es el flujo de datos de salida LISTA DE INSTALACIÓN DE SOFTWARE. Este prototipo
identifica algunos de los elementos que se deben guardar en el ARCHIVO MAESTRO DE SOFTWARE:
NÚMERO DE INVENTARIO DE SOFTWARE
NÚMERO DE VERSIÓN
NÚMERO DE CD
UBICACIÓN EN EL CAMPUS
TÍTULO
INVENTARIO DE HARDWARE
NÚMERO
UBICACIÓN DE SALA
También se examinan otros informes y pantallas del prototipo de salida. Se obtienen elementos adicionales de la pantalla
AGREGAR SOFTWARE del prototipo. Estos elementos se ordenan en una secuencia lógica para la tabla de la base de datos
del ARCHIVO MAESTRO DE SOFTWARE. Se utilizan los siguientes estándares para ordenar los elementos dentro de un
registro:
1. El elemento clave principal que identifica al registro en forma única. Un ejemplo es el NÚMERO DE INVENTARIO DE
SOFTWARE.
2. Información descriptiva como TÍTULO, NÚMERO DE VERSIÓN y EDITORIAL.
3. Información que se actualiza en forma periódica, como NÚMERO DE COPIAS.
4. Cualquier elemento repetitivo, como NÚMERO DE INVENTARIO DE HARDWARE, que identifique las máquinas en las
que se ha instalado el software.
A continuación se crea el registro ARCHIVO MAESTRO DE SOFTWARE mediante el uso del repositorio de Visible
Analyst. En la figura E8.1 se muestra la pantalla de descripción para crear un registro (Nota: Esta pantalla puede ser distinta a
la pantalla de estructura de datos en su copia de Visible Analyst. Para ver la pantalla que está en el mismo formato, haga clic en
el menú Options [Opciones] y después haga clic de manera que haya una marca de verificación en frente de Classical User
Interface [Interfaz clásica de usuario]). Observe el área de entrada para un alias, o un nombre distinto para el registro, utilizado
por un grupo de usuarios distinto. Como cada usuario puede hacer referencia al mismo registro mediante un nombre distinto,
hay que documentar todos esos nombres para mejorar la comunicación entre los usuarios.).
Cada elemento o registro estructural necesita definirse como parte del registro completo, y se introduce en el área Composition
(composición). Si el elemento o registro estructural es un grupo repetitivo, el nombre se encierra entre llaves ({ }) y se coloca el
número de veces que se repite en frente del nombre. Si los datos son claves, se coloca un código entre corchetes ([ ]) en frente del
nombre. El símbolo [pk] representa una clave primaria. El símbolo [akn] representa una clave alterna, en donde n es 1, 2, 3, etcétera,
y define a cada clave distinta o grupo de campos distintos que, al combinarse, forman una clave secundaria. Cuando un grupo de
campos forma una clave secundaria, a esa clave se le denomina clave concatenada. El símbolo [fk] representa una clave foránea.
Examine el ARCHIVO MAESTRO DE SOFTWARE. Contiene una clave primaria representada por NÚMERO DE IN-
VENTARIO DE SOFTWARE y las claves secundarias TÍTULO, EDITORIAL y CATEGORÍA DE SOFTWARE.
Visible Analyst le permite describir con facilidad cada registro estructural o elemento que compone al registro
completo. Anna coloca el cursor en cada nombre en el área Composition y hace clic en el botón Jump (Saltar).
A continuación se muestran más pantallas de registros y elementos, y se introduce información más detallada.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 253
Código de software activo +
[pk]Número de inventario de software +
[ak1]Título +
Sistema operativo +
Versión +
[ak2]Editorial +
[ak3]Categoría de software +
Marca de computadora +
Modelo de computadora +
Memoria requerida +
Licencia del sitio +
Número de copias +
Computadora de instalación +
.
Archivo maestro de software
Almacén de datos
Un archivo que contiene información sobre un paquete de Software.
Ésta es una tabla de base de datos. La clave primaria es Número
de inventario de software, con una clave secundaria representada
por Título, Número de versión y Sistema operativo.
La tabla contiene aproximadamente 2924 registros.
FIGURA E8.1
Pantalla de descripción de
registros, ARCHIVO MAESTRO
DE SOFTWARE.
“¡Excelente!” piensa Anna para sí misma. “Es muy fácil introducir los detalles, y al usar este método no olvidaré describir
un elemento”.
Chip también está impresionado con la simpleza en la creación del diccionario de datos. Con base en un proceso similar
al de Anna, crea una descripción de registro para el ARCHIVO MAESTRO DE COMPUTADORAS, que contiene una tabla de
cinco tableros internos y dos registros estructurales, EQUIPO PERIFÉRICO e INFORMACIÓN DE MANTENIMIENTO. El
área Composition para introducir los nombres de los registros o elementos es una región desplazable, lo que significa que se
pueden teclear más líneas de las que caben en el área de visualización. A medida que se agregan entradas a la parte inferior de
la región, las entradas de la parte superior se desplazan fuera del área.
A medida que se agregan elementos al registro, Chip decide describir cada uno con detalle. La pantalla de descripción de
elemento para NÚMERO DE INVENTARIO DE HARDWARE se muestra en la figura E8.2. Observe las áreas para introducir
los atributos de los elementos. Es posible incluir varios alias junto con una definición. Un área llamada Notes (Notas) contiene
El Número de inventario de hardware es un número único que
describe a una computadora específica. Es el campo de clave
primaria para el Archivo maestro de computadoras. Está unido
físicamente como una pequeña etiqueta en la máquina.
Número de inventario de hardware
Un número único asignado a cada máquina, que se localiza en forma
de una pequeña etiqueta de inventario en la máquina.
Número de inventario de computadora
FIGURA E8.2
Pantalla de descripción de
elemento, NÚMERO DE
INVENTARIO DE HARDWARE.www.xlibros.com

254 PARTE III • EL PROCESO DE ANÁLISIS
cualquier otra información útil sobre el elemento. Chip y Anna emplean esta área para agregar más criterios de edición y demás
notación útil. La descripción para el NÚMERO DE INVENTARIO DE HARDWARE detalla la forma en que se utiliza este
número para llevar un rastro físico de las máquinas.
Al hacer clic en la ficha Physical Characteristics (Características físicas) aparece una segunda pantalla para NÚMERO
DE INVENTARIO DE HARDWARE, que se muestra en la figura E8.3. Esta pantalla contiene un área que muestra las estruc-
turas dentro de las que está contenido el elemento, así como un área para el tipo de datos, la longitud y la imagen utilizada para
describir el formato de los datos. Cada imagen es una entrada codificada que indica cuál debe ser el formato del elemento. Al-
gunos ejemplos de los códigos son:
Mantenimiento de computadoras
Computadora
Sistema operativo de computadora
Hardware Software
Software
Computadora modificada
Listado de instalaciones completas
Modificaciones de computadora
Ubicación de computadora
Informe de problema de computadora
Registro de transacción de computadora
Attrib Entity -->
Class -->
Class -->
Class -->
Class -->
Data Flow -->
Data Flow -->
Data Flow -->
Data Flow -->
Data Flow -->
Data Flow -->
Número de inventario de hardware
FIGURA E8.3
NÚMERO DE INVENTARIO DE
HARDWARE, visualización de las
características del elemento.
Chip tiene cuidado de incluir entradas completas para estas áreas, incluyendo los valores predeterminados y si la entrada
puede ser nula o no.
Anna y Chip repiten este proceso para todos los elementos que se encuentran en cada registro. El esfuerzo lleva mucho
tiempo pero vale la pena. Después de crear los primeros registros se vuelve más fácil la creación del resto de las estructuras de
registros. Visible Analyst cuenta con una herramienta de búsqueda que provee listas de los elementos contenidos en el diseño.
“Creo que hemos diseñado un conjunto completo de elementos”, dice Chip en una reunión de revisión.
“Sí”, responde Anna. “Hay informes que nos mostrarán los detalles de las estructuras de datos y nos ayudarán a detectar
los elementos duplicados y las omisiones. Pongamos a Visible Analyst a trabajar para que produzca las distribuciones de los
registros por nosotros”.
Se utilizó la herramienta Reports (Informes) para imprimir las distribuciones de los registros para todos los almacenes de
datos maestros.
Análisis de registros y elementos
“Ahora sí podemos aprovechar el poder de Visible Analyst”, dice Anna. “Veamos qué tan bien hemos diseñado nuestros datos”.
“¿Qué quieres decir?”, pregunta Chip.
“He estado estudiando las herramientas de análisis que contiene Visible Analyst, y hay muchas opciones para compro-
bar la consistencia e integridad de nuestro diseño”, responde Anna. “El primer paso es usar la herramienta Reports para
producir un informe sintetizado de los elementos que agregamos. Después podemos examinar la lista en busca de duplicados
y redundancia”.
9 Representa datos numéricos: Es posible introducir sólo números al crear el prototipo.
A Alfabético: Es posible introducir sólo caracteres alfabéticos.
X Alfanumérico: Es posible introducir cualquier carácter.
Z Cero supresión: Se sustituyen los ceros a la izquierda con espacios.
$ Signo de dólares: Se sustituyen los ceros a la izquierda con un signo de dólares.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 255
La figura E8.4 es un ejemplo de una parte del informe resumido de elementos visualizado mediante Firefox. Los analistas
deben examinar con cuidado el contenido y buscar redundancia o elementos definidos más de una vez. Por lo general estas re-
dundancias son fáciles de detectar, ya que la lista está ordenada por nombre de elemento. Los elementos NÚMERO DE IN-
VENTARIO DE HARDWARE y NÚMERO DE HARDWARE, además de los elementos NÚMERO DE INVENTARIO DE
SOFTWARE y NÚM SOFTWARE parecen ser elementos duplicados. Otros duplicados, como UBICACIÓN SALA y UBICA-
CIÓN son más difíciles de detectar.
“Ahora debemos usar la opción No Location References (Sin referencias de ubicación), que muestra todos los elementos
que no se incluyen en ningún registro”, dice Anna.
“¡Es magnífico!”, exclama Chip. “Esta opción No Location References muestra el trabajo de diseño que necesita com-
pletarse. Deberíamos producir este informe para todos los componentes de diseño”.
Los elementos se agregaron a otras estructuras o se eliminaron como duplicados. Al producir el informe No Location
References una segunda vez ya no se revelaron elementos aislados.
“Bueno, creo que con eso terminamos la porción de los datos del diseño del sistema”, dice Chip.
“No tan rápido”, responde Anna. “Sólo hemos empezado a analizar. La herramienta Report Query (Consulta de informe)
nos proveerá mucha información de diseño, tanto para análisis como para documentación”.
Los analistas seleccionan un informe llamado Def Entities without Composition (Entidades definidas sin composición)
como su primera elección. Este informe muestra las entradas que son un almacén de datos o una estructura de datos y tienen
una entrada de composición. La salida muestra que no hay registros con errores. La siguiente consulta es el informe Elements
without Pictures (Elementos sin imágenes), que muestra todos los elementos que no tienen imágenes definidas. Un último
informe que crean Chip y Anna se llama Undefined Elements (Elementos indefinidos), el cual indica todos los elementos que
existan en el repositorio sólo como un nombre, pero sin características físicas.
“Todavía no terminamos. Hay algunas matrices útiles que proveerán documentación para todas las modificaciones que se
puedan hacer en el futuro. Vamos a producir la matriz Data Elements versus Data Structures (Comparación entre elementos
y estructuras de datos), que muestra a los registros y sus elementos”, sugiere Anna.
La herramienta Report tiene la capacidad de producir informes y matrices en una representación de cuadrícula. Muestra
todos los elementos y las estructuras de datos en las que están contenidos. Esta matriz se utiliza para tener acceso al efecto de
modificar un elemento, para lo cual muestra las estructuras de datos correspondientes que se deben modificar.
La siguiente matriz que se crea es Diagram Location Matrix (Matriz de ubicación de diagrama), la cual muestra a todos
los almacenes de datos y los diagramas en los que se encuentran. Esta información es útil si hay que hacer un cambio en el al-
macén de datos, ya que indicará en donde debemos cambiar los programas y la documentación.
La última matriz es Composition Matrix (Matriz de composición), la cual muestra todos los elementos de datos y los al-
macenes de datos que los contienen. Esta matriz ofrece a Chip y Anna un panorama de todos los elementos que se pueden alma-
cenar con redundancia; es decir, en varios almacenes de datos en vez de uno.
“Hay muchos otros informes y matrices que serían útiles de producir para nosotros”, dice Anna. “Algunos de ellos los
deberíamos usar posteriormente para la documentación y para rastrear los cambios propuestos. En realidad estoy satisfecha con
lo que hemos logrado”.
EJERCICIOS
Nota: Si no utiliza Visible Analyst, puede realizar algunos de los siguientes ejercicios mediante una plantilla de Microsoft Word
o Microsoft Excel. La información del repositorio se incluye en una página Web repository.html que usted puede guardar.
Fecha: 4/27/2010
Hora: 2:03:54 PM
Proyecto: CPU Página: 1
Listado sintetizado – Ordenado alfabéticamente
Todas las entradas de elementos de datos – diagramas de flujo de datos
Descripción
Elemento de datos
Descripción
Elemento de datos
Código de software activo
Código para determinar si el software está en uso en la actualidad.
El nombre del fabricante de la computadora.
Nombre de marca
Descripción
Elemento de datos
El total de una marca de computadora.
Subtotal de marca
Descripción
Elemento de datos
Un código utilizado para almacenar un edificio del campus.
Código de campus
Descripción
Elemento de datos
La descripción de un edificio del campus de la Central Pacific University.
Este campo coincide con el Código de campus.
Descripción del campus
Descripción
Elemento de datos
Campus en donde se encuentra la computadora.
Ubicación de campus
Descripción
Elemento de datos
El nombre del campus que coincide con el código del campus.
Nombre del campus
Descripción
Elemento de datos
Una entrada codificada para el tipo de software. Se guarda como tabla de Access.
Categoría de software
Descripción
Elemento de datosCiudad
FIGURA E8.4
Vista previa del resumen de los
elementos.www.xlibros.com

256 PARTE III • EL PROCESO DE ANÁLISIS
E-1. Use Visible Analyst para ver el almacén de datos ARCHIVO MAESTRO DE COMPUTADORA (COMPUTER MAS-
TER). Salte a la estructura de datos y explore los elementos y registros estructurales.
E-2. Imprima el registro del ARCHIVO MAESTRO DE SOFTWARE mediante la herramienta Report.
E-3. Use el botón Jump para avanzar a Software Record Structure. Elimine los siguientes elementos:
CÓDIGO DE SOFTWARE ACTIVO (ACTIVE SOFTWARE CODE)
COMPUTADORA DE INSTALACIÓN (INSTALLATION COMPUTER)
EXPERTO DE SOFTWARE (SOFTWARE EXPERT)
E-4. Modifique el registro MODIFICACIONES DE SOFTWARE (SOFTWARE CHANGES); suministre los cambios al re-
gistro del ARCHIVO MAESTRO DE SOFTWARE. Las modificaciones son:
a. Agregar un [pk] de clave primaria en frente del NÚMERO DE INVENTARIO DE SOFTWARE (SOFTWARE IN-
VENTORY NUMBER).
b. Agregar los siguientes elementos: MARCA DE COMPUTADORA (COMPUTER BRAND), MODELO DE COMPU-
TADORA (COMPUTER MODEL), MEMORIA REQUERIDA (MEMORY REQUIRED), LICENCIA DEL SITIO
(SITE LICENSE) y NÚMERO DE COPIAS (NUMBER OF COPIES).
E-5. Modifique el registro de TRANSACCIÓN AGREGAR COMPUTADORA (COMPUTER ADD TRANSACTION), el
cual contiene los registros de las nuevas computadoras que se van a colocar en el almacén de datos ARCHIVO MAES-
TRO DE COMPUTADORAS.
a. Inserte el NOMBRE DE MARCA (BRAND NAME) y MODELO (MODEL) arriba del NÚMERO DE SERIE (SE-
RIAL NUMBER).
b. Coloque los elementos UBICACIÓN DE CAMPUS (CAMPUS LOCATION) y UBICACIÓN DE SALA (ROOM
LOCATION) después del NÚMERO DE SERIE.
c. Agregue los siguientes elementos en la parte inferior de la lista: DISCO DURO (HARD DRIVE), DISCO DURO
SECUNDARIO (SECOND HARD DRIVE) y DISCO ÓPTICO (OPTICAL DRIVE).
E-6. Modifique la TRANSACCIÓN DE SOFTWARE INSTALADO (INSTALLED SOFTWARE TRANSACTION), que se
utiliza para actualizar el ARCHIVO MAESTRO DE SOFTWARE (SOFTWARE MASTE) y producir el LISTADO DE
INSTALACIÓN DE SOFTWARE (SOFTWARE INSTALLATION LISTING). Elimine el TÍTULO (TITLE) y NÚ-
MERO DE VERSIÓN (VERSION NUMBER), ya que se pueden obtener del ARCHIVO MAESTRO DE SOFTWARE
y son tecleo redundante. Agregue el NÚMERO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY
NUMBER) y especifique la computadora de instalación. Elimine UBICACIÓN DE CAMPUS (CAMPUS LOCATION)
y UBICACIÓN DE SALA (ROOM LOCATION), ya que son elementos de la computadora de instalación.
E-7. Vea la entrada de alias para MODIFICACIONES DE SOFTWARE (SOFTWARE CHANGES).
E-8. Modifique el almacén de datos SOFTWARE INSTALADO (INSTALLED SOFTWARE). Agregue el registro de com-
posición TRANSACCIÓN DE SOFTWARE INSTALADO (INSTALLED SOFTWARE TRANSACTION). Los elemen-
tos índices son NÚMERO DE INVENTARIO DE SOFTWARE (SOFTWARE INVENTORY NUMBER) y NÚMERO
DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY NUMBER).
E-9. Defina el almacén de datos ARCHIVO DE REGISTRO DE SOFTWARE (SOFTWARE LOG FILE). Este archivo se
utiliza para almacenar información sobre los nuevos registros de software además de la fecha, hora e ID de usuario de la
persona que introduce el registro. Los elementos índices son NÚMERO DE INVENTARIO DE SOFTWARE, TÍTULO,
VERSIÓN (una clave concatenada) y CATEGORÍA DE SOFTWARE (SOFTWARE CATEGORY).
E-10. Defina el almacén de datos PEDIDOS DE COMPUTADORAS PENDIENTES (PENDING COMPUTER ORDERS).
Este archivo se crea cuando se crea una orden de compra para ordenar nuevas computadoras; el sistema de computadora
se encarga de actualizarlo. Coloque un comentario en el área Notes para declarar que el número promedio de registros
es de 100. Los elementos índices son NÚMERO DE ORDEN DE COMPRA (PURCHASE ORDER NUMBER) y una
clave concatenada que consiste de NOMBRE DE MARCA (BRAND NAME) y MODELO (MODEL).
E-11. Vea la entrada para el flujo de datos REGISTRO DE SOFTWARE (SOFTWARE RECORD). Haga clic en Jump con el
cursor en el área Composition y examine el registro del ARCHIVO MAESTRO DE SOFTWARE (SOFTWARE MAS-
TER). Haga clic en Back para regresar a la pantalla de descripción del flujo de datos.
E-12. Modifique el flujo de datos INFORMACIÓN DE ACTUALIZACIÓN DE SOFTWARE (software UPGRADE INFOR-
MATION). El registro de composición es INFORMACIÓN DE ACTUALIZACIÓN DE SOFTWARE.
E-13. Modifique el flujo de datos INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS-REFE-
RENCE REPORT). El registro de composición es INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE.
E-14. Modifique la entidad del diagrama de flujo para INSTALAR ACTUALIZACIÓN (INSTALL UPDATE). Este flujo ac-
tualiza el registro del ARCHIVO MAESTRO DE COMPUTADORAS (COMPUTER MASTER) con información sobre
la instalación. Su estructura de datos es REGISTRO DE ACTUALIZACIÓN DE INSTALACIÓN (INSTALL UPDATE
RECORD). Incluya un comentario de que procesa aproximadamente 50 registros por mes al actualizar el ARCHIVO
MAESTRO DE COMPUTADORAS.www.xlibros.com

CAPÍTULO 8 • ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS 257
E-15. Use el flujo de datos INSTALAR ACTUALIZACIÓN (INSTALL UPDATE) para saltar al (y crear el) REGISTRO DE
ACTUALIZACIÓN DE INSTALACIÓN (INSTALL UPDATE RECORD). Provea una definición con base en la infor-
mación suministrada en el problema anterior. Escriba los siguientes elementos:
NÚMERO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY NUMBER) (clave primaria)
UBICACIÓN DE CAMPUS (CAMPUS LOCATION)
DISCO DURO (HARD DRIVE)
INTERVALO DE MANTENIMIENTO (MAINTENANCE INTERVAL)
FECHA EN QUE SE INSTALÓ (DATE INSTALLED)
E-16. Cree la descripción del flujo de datos para la LISTA DE INSTALACIÓN DE SOFTWARE (SOFTWARE INSTALLA-
TION LIST). Este flujo contiene información sobre paquetes de software específicos y las máquinas en las que se debe
instalar el software. La composición debe incluir el LISTADO DE INSTALACIÓN DE SOFTWARE (SOFTWARE
INSTALLATION LISTING), una estructura de datos.
E-17. Use la LISTA DE INSTALACIÓN DE SOFTWARE para saltar al (y por lo tanto crear el) LISTADO DE INSTALACIÓN
DE SOFTWARE. Los elementos en el listado son:
NÚMERO DE INVENTARIO DE SOFTWARE (SOFTWARE INVENTORY NUMBER)
TÍTULO (TITLE)
NÚMERO DE VERSIÓN (VERSION NUMBER)
HARDWARE INVENTORY NUMBER (NÚMERO DE INVENTARIO DE HARDWARE)
UBICACIÓN DE CAMPUS (CAMPUS LOCATION)
UBICACIÓN DE SALA (ROOM LOCATION)
E-18. Modifique e imprima el elemento SUBTOTAL DE HARDWARE (HARDWARE SUBTOTAL). Cambie el tipo a Deci-
mal, la longitud a 7.2 y la imagen a Z, ZZZ, ZZ9.99.
E-19. Modifique el elemento TIPO DE COMPUTADORA (COMPUTER TYPE). La descripción debería ser: el tipo físico de
computadora. Valores y significados (Values & Meanings) debe contener: L—Laptop, D—Desktop, N—Netbook,
P—Portátil. El tipo es Char con una Longitud (Length) de 1, y una Imagen y Visualización (Picture and Display) de X.
No debe permitir un valor nulo.
E-20. Modifique e imprima el elemento NOMBRE DEL DEPARTAMENTO (DEPARTMENT NAME). Cree un alias de
NOMBRE DEPARTAMENTO PERSONAL (STAFF DEPARTMENT NAME). En el área Notes escriba el siguiente
comentario: Tabla de códigos: Tabla Departamento. El tipo debe ser Character, la longitud 25 y la imagen X(25).
E-21. Cree las siguientes descripciones de elementos. Use los valores que se suministran en la tabla. Cree nombres y definicio-
nes alternativas con base en su comprensión del elemento.
E-22. Use la herramienta Repository Reports de Visible Analyst para producir los siguientes informes y matrices, ya sea al
imprimir los informes o ver una vista previa de los mismos mediante su navegador Web. Se listan los criterios de selección
del cuadro de diálogo Repository Reports, separados con una barra diagonal (/). Explique en un párrafo en dónde se
puede usar efectivamente la información producida.
Nombre NÚMERO DE ORDEN DE COMPRA DESCRIPCIÓN DEL PROBLEMA
Tipo Carácter Carácter
Longitud 7 70
Imagen 9999999 X(70)
Nombre COSTO TOTAL COMPUTADORA FECHA DE SIGUIENTE MANTENIMIENTO
PREVENTIVO
Tipo Numérico Fecha
Longitud 7.2 8
Imagen Z, ZZZ, ZZ9,99 Z9/99/9999
Notas La FECHA DE SIGUIENTE MANTENIMIENTO
PREVENTIVO se calcula al sumar el INTERVALO DE
MANTENIMIENTO a la FECHA DEL ÚLTIMO
MANTENIMIENTO PREVENTIVO
Nombre NÚMERO TELEFÓNICO ESTADO DE REPARACIÓN
Tipo Carácter Carácter
Longitud 7 1
Imagen 999-9999 X
Notas Tabla de códigos: Tabla Reparación
Predeterminado Cwww.xlibros.com

258 PARTE III • EL PROCESO DE ANÁLISIS
a. Data Flow/Cross-Reference Listing/Data Element/Entire Project
b. Data Flow/Cross-Reference Listing/Data Structure/Entire Project
c. Record Contains Element (One Level) Matrix
d. Data Flow/Single-Entry Listing/Software Master—Normalized
e. Data Flow/Diagram Location Matrix/Data Stores versus Diagrams
f. Data Flow/Composition Matrix/Data Elements versus Data Flows
g. Data Flow/Composition Matrix/Data Elements versus Data Structures
h. Data Flow/Composition Matrix/Data Elements versus Data Stores
E-23. Use la herramienta Report Query de Visible Analyst para producir los siguientes informes. Explique en un enunciado
qué información le provee el informe.
a. El informe Undefined Elements
b. El informe Elements without Pictures
c. El informe Coded Elements
d. El informe Any Item with Components
E-24. Use Visible Analyst para imprimir un informe sintetizado para todos los componentes de flujo de datos que no tengan
una descripción. (Sugerencia: Haga clic en el botón de opción No Descriptive Info.).
E-25. Use Visible Analyst para imprimir un informe sintetizado para todos los componentes de flujo de datos que no estén en
un diagrama. (Sugerencia: Haga clic en el botón de opción No Location References.).
E-26. Use Visible Analyst para imprimir un informe detallado para todos los elementos. Incluya sólo la información física,
además de los valores y los significados (sugerencia: haga clic en el botón Fields y después en el botón Invert; después
seleccione los campos que desee imprimir). ¿Por qué sería útil este informe para el analista?
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.www.xlibros.com

259
C A P Í T U L O 9
Especificaciones
de los procesos y decisiones
estructuradas
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender el propósito de las especificaciones de los procesos.
2. Reconocer la diferencia entre las decisiones estructuradas y las semiestructuradas.
3. Usar español estructurado, tablas y árboles de decisión para analizar, describir y
documentar las decisiones estructuradas.
4. Elegir un método apropiado para analizar las decisiones estructuradas y crear
especificaciones de los procesos.
El analista de sistemas que se enfoca en las especificaciones de los procesos y
las decisiones estructuradas tiene muchas opciones para documentarlas
y analizarlas. En los capítulos 7 y 8 vimos procesos como VERIFICAR Y CALCU-
LAR CUOTAS, pero no explicamos la lógica necesaria para ejecutar estas
tareas. Los métodos disponibles para documentar y analizar la lógica de las
decisiones incluyen español estructurado, tablas y árboles de decisión. Es
importante ser capaces de reconocer las decisiones lógicas y estructuradas que ocurren en una
empresa y cómo podemos diferenciarlas de las decisiones semiestructuradas que tienden a
involucrar el juicio humano. Así, es imprescindible reconocer que las decisiones estructuradas se
prestan particularmente bien al análisis con métodos sistemáticos que promueven la integridad,
precisión y comunicación.
GENERALIDADES DE LAS ESPECIFICACIONES DE LOS PROCESOS
Para determinar los requerimientos humanos de información de una estrategia de análisis de
decisiones, el analista de sistemas debe primero determinar los objetivos de los usuarios junto
con los objetivos de la organización, ya sea mediante el uso de una metodología arriba-abajo
o una metodología orientada a objetos. El analista de sistemas debe comprender los principios
de las organizaciones, además de contar con un conocimiento práctico sobre las técnicas de
recopilación de datos. La metodología arriba-abajo es imprescindible, ya que todas las decisio-
nes humanas en la organización deben estar relacionadas, al menos en forma indirecta, con los
objetivos generales de toda la organización.
Las especificaciones de los procesos (a las que algunas veces se les denomina mini-especifi-
caciones, debido a que son una pequeña parte de las especificaciones totales del proyecto) se crean
para procesos primitivos en un flujo de diagrama de datos, así como para algunos procesos de ni-
vel más alto que se expanden en un diagrama hijo. También se pueden crear para los métodos de
clases en el diseño orientado a objetos y, en un sentido más general, para los pasos en un caso de uso
(como se ve en los capítulos 2 y 10). Estas especificaciones explican la lógica de la toma de decisio-
nes y las fórmulas que transformarán la entrada del proceso en su salida. Cada elemento derivado
debe tener lógica de proceso para mostrar cómo se produce desde los elementos base u otros ele-
mentos derivados creados con anterioridad que actúen como entrada para el proceso primitivo.www.xlibros.com

260 PARTE III • EL PROCESO DE ANÁLISIS
Los tres objetivos al producir especificaciones de procesos son:
1. Reducir la ambigüedad del proceso. Este objetivo obliga al analista a aprender los detalles acerca de la
forma en que trabaja el proceso. Hay que detectar las áreas imprecisas, anotarlas y consolidarlas para todas
las especificaciones de los procesos. Estas observaciones forman una base y proveen las preguntas para las
entrevistas de seguimiento con la comunidad de usuarios.
2. Obtener una descripción precisa de lo que se va a lograr, que por lo general se incluye en un paquete de
especificaciones para el programador.
3. Validar el sistema de diseño. Este objetivo incluye asegurar que un proceso tenga todo el flujo de datos de
entrada necesario para producir la salida. Además, todas las entradas y salidas se deben representar en el
diagrama de flujo de datos.
Usted se encontrará con muchas situaciones en las que no se hayan creado las especificaciones de los proce-
sos. Algunas veces el proceso es muy simple o ya existe el código de computadora. Hay que tomar nota de esta
eventualidad en la descripción del proceso y no se requiere ningún diseño adicional. Las categorías o procesos
que por lo general no requieren especificaciones son:
1. Procesos que representan entrada o salida física, como lectura y escritura. Por lo general estos procesos
requieren sólo una lógica simple.
2. Procesos que representan una validación de datos simple, lo cual por lo general es bastante fácil de lograr.
Los criterios de edición se incluyen en el diccionario de datos y se incorporan en el código fuente de
computadora. Se pueden producir especificaciones de procesos para una edición compleja.
3. Procesos que utilizan código escrito con anterioridad. Comúnmente estos procesos se incluyen en un sistema
como procedimientos, métodos y funciones, o en bibliotecas de clases (que se pueden comprar o están
disponibles en forma gratuita a través de Web).
Estos bloques son código de programa de computadora que se almacena en el sistema computarizado. Por
lo general realizan una función general del sistema, como validar una fecha o un dígito de verificación. Estos
subprogramas de propósito general se escriben y documentan sólo una vez, pero forman una serie de bloques
de construcción que se pueden usar en muchos sistemas en toda la organización. Por ende, estos subprogramas
aparecen como procesos en muchos diagramas de flujo de datos (o como métodos de clases, lo cual veremos en
el capítulo 10).
Formato de especificación de proceso
Las especificaciones de procesos vinculan a un proceso con el diagrama de flujo de datos y también con el
diccionario de datos, como se muestra en la figura 9.1. Cada especificación de proceso se debe introducir en un
formulario separado o en la pantalla de una herramienta CASE, como la que se usa para Visible Analyst y se
muestra en el caso de la CPU al final de este capítulo. Debe introducir la siguiente información:
1. El número del proceso, que debe coincidir con el ID del proceso del diagrama de flujo de datos. Esta
especificación permite a un analista trabajar en cualquier proceso o revisarlo, además de que puede localizar
con facilidad el diagrama de flujo de datos que contiene el proceso.
2. El nombre del proceso, que además debe ser el mismo que el nombre mostrado en el símbolo del proceso en
el diagrama de flujo de datos.
3. Una descripción breve de lo que logra el proceso.
4. Una lista de flujos de datos de entrada, que utilice los nombres que se encuentran en el diagrama de flujo
de datos. Los nombres de los datos utilizados en la fórmula o lógica deben coincidir con los del diccionario de
datos para asegurar la consistencia y la buena comunicación.
5. Los flujos de datos de salida, que también utilicen los nombres del diagrama de flujo de datos y del
diccionario de datos.
6. Una indicación del tipo de proceso: por lotes, en línea o manual. Todos los procesos en línea requieren
diseños de pantallas y todos los procesos manuales deben tener procedimientos bien definidos para los
empleados que realizan las tareas del proceso.
7. Si el proceso utiliza código escrito con anterioridad, incluya el nombre del subprograma o función que
contiene ese código.
8. Una descripción de la lógica del proceso que establece la política y las reglas de negocios en lenguaje
cotidiano, no en lenguaje de seudocódigo de computadora. Las reglas de negocios son los procedimientos, o
tal vez un conjunto de condiciones o fórmulas, que permiten a una empresa operar su negocio. La definición
anticipada del problema (como vimos en el capítulo 3) que usted completó en un principio puede proveer un
punto de inicio para esta descripción. Los formatos de las reglas de negocios comunes son:
• Definiciones de los términos de negocios.
• Condiciones y acciones de negocios.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 261
• Restricciones de integridad de los datos.
• Derivaciones matemáticas y funcionales.
• Inferencias lógicas.
• Secuencias de procesamiento.
• Relaciones entre los hechos acerca de la empresa.
9. Si no hay suficiente espacio en el formulario para una descripción completa en español estructurado, o si
hay una tabla o árbol de decisión que describa la lógica, incluya el nombre de la tabla o árbol
correspondiente.
10. Haga una lista de todos los problemas sin resolver, las porciones incompletas de lógica o cualquier otra
cuestión relacionada. Estas cuestiones forman la base de las preguntas utilizadas para las entrevistas de
seguimiento con los usuarios o expertos de negocios que usted agregó a su equipo del proyecto.
Hay que introducir estos elementos para completar un formulario de especificación de proceso, el cual incluye
el número del proceso, su nombre o ambos elementos del diagrama de flujo de datos, así como los otros ocho
elementos que se muestran en el ejemplo de World’s Trend (figura 9.2). Cabe mencionar que si completamos este
formulario con el mayor detalle posible, será más fácil vincular el proceso con el diagrama de flujo de datos y el
diccionario de datos.
ESPAÑOL ESTRUCTURADO
Cuando la lógica del proceso involucra fórmulas o iteraciones, o cuando las decisiones estructuradas no son
complejas, una técnica apropiada para analizar el proceso de decisión es el uso del español estructurado. Como
su nombre indica, el español estructurado se basa en 1) la lógica estructurada, o las instrucciones organizadas en
procedimientos anidados y agrupados, y 2) las instrucciones en español simple tales como sumar, multiplicar y
mover. Un problema escrito se puede transformar en español estructurado si ponemos las reglas de decisión en su
secuencia apropiada y usamos la convención de las instrucciones IF-THEN-ELSE a lo largo del proceso.
Cómo escribir español estructurado
Para escribir español estructurado es conveniente utilizar las siguientes convenciones:
1. Expresar toda la lógica en términos de uno de estos cuatro tipos: estructuras secuenciales, estructuras de
decisión, estructuras de casos o iteraciones (en la figura 9.3 podrá ver ejemplos).
Formulario de
especificación
de proceso
Árbol de
decisión
X
P
Q
T
20 40
50
10
30
Proceso
Diagrama de flujo de datos Especificación y lógica de proceso
Español
estructurado
Tabla de
decisión
Reglas
2' 3' 4'1'
Y
Y Y Y
X
X X
N
N
I F c o n s t r u c c i ó n
T H E N d e d u c
E N D I F
I F r e e m p l a z o
T H E N s u m a r 1
E N D I F
I F p r o p i e t a r i o e l i g i ó
T H E N s u m a r 1
E N D I F
FIGURA 9.1
Cómo se relacionan las
especificaciones de los procesos
con el diagrama de flujo de datos.www.xlibros.com

262 PARTE III • EL PROCESO DE ANÁLISIS
Formulario de especificación de proceso
Número
Nombre
Descripción
Flujo de datos de entrada
Flujo de datos de salida
Tipo de proceso
En línea Por lotes Manual
Nombre de subprograma/función
Lógica del proceso
Referir a: Nombre:
Español estructurado Tabla de decisión Árbol de decisión
Cuestiones sin resolver:
1.3
Determinar cantidad disponible
Determinar si un artículo está disponible para su venta. Si no está disponible,
crear un registro de artículo pendiente. Determinar la cantidad disponible.
Artículo válido del proceso 1.2
Cantidad disponible del registro del artículo
Artículo disponible (Número de artículo + Cantidad vendida) para los procesos 1.4 y 1.5
Artículo pendiente a control de inventario
IF la Cantidad artículo pedido es mayor que Cantidad disponible
THEN Mover Cantidad artículo pedido a Cantidad disponible artículo
Mover Número artículo pedido a Número artículo disponible
ELSE
Restar Cantidad disponible de Cantidad artículo pedido
para producir Cantidad pendiente
Mover Cantidad pendiente a Registro artículos pendientes
Mover Número artículo a Registro artículos pendientes
DO escribir Registro pendiente
Mover Cantidad disponible a Cantidad disponible artículo
Mover Número artículo pedido to Número artículo disponible
ENDIF
¿Habrá que tomar en cuenta la cantidad que está en el pedido para este
artículo? Si combinamos esto con la fecha esperada de la llegada de los artículos en el pedido,
¿cambiaría la forma en que se calcula la cantidad?
FIGURA 9.2
Un ejemplo de formulario de especificación de proceso
completado para determinar si un artículo está disponible.
2. Usar y poner en mayúsculas las palabras clave aceptadas como IF, THEN, ELSE, DO, DO WHILE, DO
UNTIL y PERFORM.
3. Aplicar sangría a los bloques de instrucciones para mostrar su jerarquía (anidamiento) con claridad.
4. Cuando haya palabras o frases definidas en un diccionario de datos (como en el capítulo 8), subraye esas
palabras o frases para indicar que tienen un significado especializado y reservado.
5. Tenga cuidado al usar “y” y “o”, y evite la confusión al diferenciar entre “mayor que” y “menor o igual que”
y con las relaciones de igualdad. “A y B” significa tanto A como B; “A” o “B” significa que puede ser A o B,
pero no ambas. Aclare las instrucciones lógicas ahora, en vez de esperar hasta la etapa de codificación del
programa.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 263
Tipo de español estructurado
Estructura secuencial
Un bloque de instrucciones en las
que no ocurre bifurcación
Acción #1
Acción #2
Acción #3
IF condición A es verdadera
THEN implementar Acción A
ELSE implementar Acción B
ENDIF
IF Caso # 1 implementar Acción #1
ELSE IF Caso #2
Implementar Acción #2
ELSE IF Caso #3
Implementar Acción #3
ELSE IF Caso #4
Implementar Acción #4
ENDIF
Estructura de decisión
Sólo SI (IF) una condición es
verdadera, completar las siguientes
instrucciones; en caso contrario,
ir al ELSE
Estructura de caso
Un tipo especial de estructura de
decisión en la que los casos son
mutuamente excluyentes (si ocurre
uno, los otros no pueden ocurrir)
Iteración
Bloques de instrucciones que se
repiten hasta terminar
DO WHILE haya clientes.
Acción #1
ENDDO
Ejemplo FIGURA 9.3
Ejemplos de la lógica expresada
en una estructura secuencial, una
estructura de decisión, una
estructura de caso y una iteración.
UN EJEMPLO DE ESPAÑOL ESTRUCTURADO El siguiente ejemplo demuestra cómo se transforma un procedimiento
hablado para procesar reclamaciones médicas en español estructurado:
Procesamos todas nuestras reclamaciones de esta forma. Primero determinamos si el solicitante ha
presentado alguna reclamación antes; si no es así, establecemos un nuevo registro. Después se actualizan
O P O R T U N I D A D D E C O N S U L T O R Í A 9 . 1
Kit Chen Kaboodle, Inc.
“No quiero que se agiten, pero creo que necesitamos dar un vis-
tazo a nuestras políticas de pedidos incompletos”, dice Kit Chen. “No
me gustaría presionar a nuestros clientes. Como saben de antemano,
Kit Chen Kaboodle es una empresa de venta de utensilios de cocina a
través de Web y por correo convencional, que se especializa en ‘kitsch
elegante para cocinas’ como dice nuestro catálogo más reciente. Es
decir, tenemos todo lo necesario para la cocina gourmet y entreteni-
miento: molinillos de nuez moscada, batidoras de papas, separadores
de huevos, jeringas para pavos, manteles individuales con gatos, bande-
jas para cubos de hielo en forma de tréboles y mucho más.
“He aquí la forma en que hemos estado manejando los pedidos
incompletos. Buscamos en nuestro archivo de pedidos incompletos
de Internet, así como las ventas de pedidos por correo, una vez por
semana. Si el pedido se completó esta semana, eliminamos el regis-
tro y el resto es pan comido. Si no hemos escrito al cliente en cuatro
semanas, les enviamos esta linda tarjeta con un chef asomándose al
horno, diciendo: ‘No está listo todavía’ (es una notificación de que
su artículo sigue pendiente)”.
“Si cambió la fecha del pedido pendiente a más de 45 días a
partir de hoy, enviamos un aviso. Pero si la mercancía es de tempo-
rada (como con las bolsas para dulces de Halloween, los cortadores
de galletas de Navidad o los moldes de pasteles del día de San Va-
lentín) y la fecha del pedido pendiente es de 30 días o más, envia-
mos un aviso con un chef mirando su temporizador”.
“Si la fecha del pedido pendiente cambió y no hemos enviado
una tarjeta en las últimas dos semanas, enviamos una tarjeta con un
chef revisando su receta. Si la mercancía ya no está disponible,
enviamos un aviso (con todo y el chef llorando en la esquina) y
eliminamos el registro. No hemos empezado a usar el correo elec-
trónico en vez de las tarjetas enviadas por correo, pero me gustaría
hacerlo”.
“Gracias por escuchar todo esto. Creo que tenemos los ingre-
dientes apropiados para una buena política; sólo necesitamos mez-
clarlos y cocinar algo especial”.
Como usted es el analista de sistemas que Kit contrató, repase
la narrativa de cómo Kit Chen Kaboodle, Inc. Maneja los pedidos
incompletos. Dibuje cuadros alrededor de cada acción que men-
ciona Kit y circule cada condición que vaya surgiendo. Haga una
lista de las ambigüedades que quiera aclarar en una entrevista pos-
terior y después escriba cinco preguntas a tratar en la entrevista.www.xlibros.com

264 PARTE III • EL PROCESO DE ANÁLISIS
O P O R T U N I D A D D E C O N S U L T O R Í A 9 . 2
Estructura para amasar
Kit Chen se puso a la altura de las circunstancias y respondió a sus
preguntas relacionadas con el manejo de los pedidos incompletos en
Kit Chen Kaboodle, Inc. Con base en esas respuestas y las suposicio-
nes que tenga que hacer, vacíe la narrativa de Kit (de la Oportunidad
de consultoría 9.1) en un nuevo molde; vuelva a escribir la receta para
manejar pedidos incompletos en español estructurado. Describa en
un párrafo cómo podría cambiar este proceso si para las notificacio-
nes utilizara correo electrónico en vez de correo convencional.
DO WHILE haya reclamaciones restantes
IF solicitante no ha presentado una reclamación
THEN establecer un nuevo registro de solicitante
ELSE continuar
Agregar reclamación a reclamación AAF
IF solicitante tiene plan de póliza A
THEN IF deducible de $100.00 no se ha cumplido
THEN restar deducible no cumplido a reclamación
Actualizar deducible
ELSE continuar
ENDIF
Restar copago de 40% de reclamación a reclamación
ELSE IF solicitante tiene plan de póliza B
THEN IF deducible de $50.00 no se ha cumplido
THEN restar deducible no cumplido a reclamación
Actualizar deducible
ELSE continuar
ENDIF
Restar copago de 60% de reclamación a reclamación
ELSE continuar
ELSE escribir mensaje de error en plan
ENDIF
IF reclamación es mayor que cero
THEN imprimir cheque
ENDIF
Imprimir resumen para solicitante
Actualizar cuentas
ENDDO
FIGURA 9.4
Español estructurado para el
sistema de procesamiento de
reclamaciones médicas. Los
elementos subrayados indican que
se definieron los términos en el
diccionario de datos.
los totales de las reclamaciones para el año. Luego determinamos si un solicitante tiene la póliza A o B,
que difieren en los deducibles y los copagos (el porcentaje de la reclamación que tienen que pagar los
solicitantes). Para ambas pólizas revisamos si se cumple con el deducible ($100 para la póliza A y $50
para la póliza B). Si no se cumple con el deducible, aplicamos la reclamación al deducible. En otro paso
se ajusta el copago; restamos el porcentaje que paga el solicitante (40 por ciento para la póliza A y 60 por
ciento para la póliza B) de la reclamación. Después emitimos un cheque si el solicitante va a recibir
dinero, imprimimos un resumen de la transacción y actualizamos nuestras cuentas. Hacemos esto hasta
que se procesan todas las reclamaciones de ese día.
Al examinar las declaraciones anteriores podemos observar algunas estructuras de secuencia simples, en especial
al inicio y al final. Hay un par de estructuras de decisión y lo más apropiado es anidarlas, para lo cual primerowww.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 265
hay que determinar qué póliza (A o B) usar y después hay que restar los deducibles y copagos correctos. El
último enunciado apunta a una iteración: HACER HASTA (DO UNTIL) que todas las reclamaciones se hayan
procesado o HACER MIENTRAS (DO WHILE) haya reclamaciones pendientes.
Si consideramos que es posible anidar las estructuras de decisión de acuerdo con los planes de las pólizas,
podemos escribir el español estructurado para el ejemplo anterior (vea la figura 9.4). A medida que empiece
a trabajar en el español estructurado descubrirá que una parte de la lógica y las relaciones que parecían claras
una vez son en realidad ambiguas. Por ejemplo, ¿debemos agregar la reclamación a la reclamación del año a la fecha
(AAF) antes o después de actualizar el deducible? ¿Es posible que ocurra un error si se almacena algo que no
sea la póliza A o B en el registro del solicitante? ¿A qué restamos el 40 por ciento de la reclamación? Hay que
aclarar estas ambigüedades en este punto.
Además de la obvia ventaja de aclarar la lógica y las relaciones que se encuentran en los lenguajes humanos,
el español estructurado tiene otra ventaja importante: es una herramienta de comunicación. Podemos enseñar a
los usuarios en la organización el español estructurado para que lo comprendan, por lo que si es importante la
comunicación, el español estructurado es una alternativa viable para el análisis de decisiones.
Diccionario de datos y especificaciones de procesos
Todos los programas de computadora se pueden codificar mediante el uso de tres construcciones básicas: secuen-
cia, selección (IF...THEN...ELSE y la estructura de caso), e iteración o ciclo. El diccionario de datos indica
cuáles de estas construcciones se deben incluir en las especificaciones de los procesos.
Si el diccionario de datos para el flujo de datos de entrada y salida contiene una serie de campos sin ninguna
iteración —{ }— o selección —[ ]—, la especificación de proceso contendrá una secuencia simple de instruc-
ciones, como MOVER, SUMAR y RESTAR. Consulte el ejemplo de un diccionario de datos para el ESTADO
DE CUENTA DE ENVÍO que se muestra en la figura 9.5. Cabe mencionar que el diccionario de datos para el
ESTADO DE CUENTA DE ENVÍO tiene los elementos NÚMERO DE PEDIDO, FECHA DEL PEDIDO y
Estado de cuenta de envío = Número de pedido +
Fecha del pedido +
Número de cliente +
Nombre del cliente +
Dirección del cliente +
5
{Líneas de artículos del pedido} +
Número de artículos +
Total de mercancía +
(Impuestos) +
Envío y manejo +
Total del pedido
Primer nombre +
(Inicial segundo nombre) +
Apellido paterno
Calle +
(Departamento) +
Ciudad +
Estado +
CP +
(Expansión CP) +
(País)
Número de artículo +
Cantidad ordenada +
Cantidad pendiente +
Descripción del artículo +
Descripción del tamaño +
Descripción del color +
Precio unitario +
Monto extendido +
Nombre del cliente =
Dirección =
Líneas de artículos del pedido =
1
FIGURA 9.5
Estructura de datos para un estado
de cuenta de envío de World’s
Trend.www.xlibros.com

266 PARTE III • EL PROCESO DE ANÁLISIS
NÚMERO DE CLIENTE como simples campos secuenciales. La lógica correspondiente, que se muestra en las
líneas 3 a la 5 en el correspondiente español estructurado en la figura 9.6, consiste de instrucciones MOVER
simples.
Una estructura de datos con elementos opcionales contenidos entre paréntesis o elementos ya sea/o conteni-
dos entre corchetes, tendrán su correspondiente instrucción IF...THEN...ELSE en la especificación del proceso.
Además, si un monto tal como CANTIDAD PENDIENTE es mayor que cero, la lógica subyacente será IF...
THEN...ELSE. La iteración, que se indica mediante llaves en una estructura de datos, debe tener una instrucción
correspondiente DO WHILE, DO UNTIL o PERFORM UNTIL para controlar los ciclos en la especificación del
proceso. La estructura de datos para LÍNEAS DE ARTÍCULOS DEL PEDIDO permite hasta cinco artículos en
el ciclo. Las líneas 8 a la 17 muestran las instrucciones contenidas en el DO WHILE hasta el END DO necesa-
rias para producir las diversas LÍNEAS DE ARTÍCULOS DEL PEDIDO.
TABLAS DE DECISIÓN
Una tabla de decisión es una tabla de filas y columnas, separada en cuatro cuadrantes, como se muestra en la figura
9.7. El cuadrante superior izquierdo contiene la(s) condición(es); el cuadrante superior derecho contiene las alter-
nativas de condiciones. La mitad inferior de la tabla contiene las acciones a realizar a la izquierda y las reglas para
ejecutar las acciones a la derecha. Cuando se utiliza una tabla de decisión para determinar la acción a realizar, la
lógica se mueve en sentido de las manecillas del reloj, partiendo desde el cuadrante superior izquierdo.
Español estructurado
GET Registro de pedido
GET Registro de cliente
Mover Número de pedido a estado de cuenta de envío
Mover Fecha del pedido a Estado de cuenta de envío
Mover Número de cliente a Estado de cuenta de envío
DO aplicar formato a Nombre del cliente (dejar sólo un espacio entre Primer/Segundo/Apellido)
DO aplicar formato a las líneas de Dirección del cliente
DO WHILE haya artículos para el pedido
GET Registro de artículo
DO Aplicar formato a Línea de artículo
Multiplicar Precio unitario por Cantidad ordenada para obtener Monto extendido
Mover Monto extendido a Líneas de artículos del pedido
Sumar Monto extendido a Total de mercancía
IF Cantidad pendiente es mayor que cero
Mover Cantidad pendiente a Líneas de artículos del pedido
ENDIF
ENDDO
Mover Total de mercancía a Estado de cuenta de envío
Mover 0 a Impuestos
IF Estado es igual a CT
Multiplicar Total de mercancía por Tasa de impuestos para obtener Impuesto
ENDIF
Mover Impuesto a Estado de cuenta de envío
DO calcular Envío y manejo
Mover Envío y manejo a Estado de cuenta de envío
Sumar Total de mercancía, Impuestos y Envío y manejo para obtener Total del pedido
Mover Total del pedido a Estado de cuenta de envío
GET Registro de pedido
GET Registro de cliente
Mover Número de pedido a estado de cuenta de envío
Mover Fecha del pedido a Estado de cuenta de envío
Mover Número de cliente a Estado de cuenta de envío
DO aplicar formato a Nombre del cliente (dejar sólo un espacio entre Primer/Segundo/Apellido)
DO aplicar formato a las líneas de Dirección del cliente
DO WHILE haya artículos para el pedido
GET Registro de artículo
DO Aplicar formato a Línea de artículo
Multiplicar Precio unitario por Cantidad ordenada para obtener Monto extendido
Mover Monto extendido a Líneas de artículos del pedido
Sumar Monto extendido a Total de mercancía
IF Cantidad pendiente es mayor que cero
Mover Cantidad pendiente a Líneas de artículos del pedido
ENDIF
ENDDO
Mover Total de mercancía a Estado de cuenta de envío
Mover 0 a Impuestos
IF Estado es igual a CT
Multiplicar Total de mercancía por Tasa de impuestos para obtener Impuesto
ENDIF
Mover Impuesto a Estado de cuenta de envío
DO calcular Envío y manejo
Mover Envío y manejo a Estado de cuenta de envío
Sumar Total de mercancía, Impuestos y Envío y manejo para obtener Total del pedido
Mover Total del pedido a Estado de cuenta de envío
Aplique formato al Estado de cuenta de envío. Una vez que haya aplicado formato a cada
línea del estado de cuenta, escriba la línea de envío.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
FIGURA 9.6
Español estructurado para crear el
estado de cuenta de envío para
World’s Trend.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 267
Condiciones y acciones
Condiciones
Acciones
Reglas
Alternativas de condiciones
Entradas de acciones
FIGURA 9.7
El formato estándar utilizado para
presentar una tabla de decisión.
Suponga que una tienda desea ilustrar su política sobre compras que no son en efectivo. La empresa podría
hacerlo mediante el uso de una tabla de decisión simple, como se muestra en la figura 9.8. Cada una de las tres
condiciones (venta menor de $50, paga con cheque y usa tarjetas de crédito) sólo tiene dos alternativas. Las dos
alternativas son Y (sí, es verdadero) o N (no, no es verdadero). Es posible realizar cuatro acciones:
1. Completar la venta después de verificar la firma.
2. Completar la venta. No se necesita firma.
3. Llamar al supervisor para la aprobación.
4. Comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito.
El ingrediente final que hace que valga la pena usar la tabla de decisión es el conjunto de reglas para cada
una de las acciones. Las reglas son las combinaciones de las alternativas de condiciones que precipitan una ac-
ción. Por ejemplo, la regla 3 dice:
El ejemplo anterior presenta un problema con cuatro conjuntos de reglas y cuatro posibles acciones, pero
Condiciones y acciones
Menor de $50
Paga con cheque con dos formas de ID
Usa tarjeta de crédito
Completar la venta después de verificar la firma.
Completar la venta. No se necesita firma.
Llamar al supervisor para la aprobación.
Comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito.
Reglas
1
Y Y N N
Y N Y N
N
X
Y
X
N
X
Y
X
2 3 4
FIGURA 9.8
Uso de una tabla de decisión para
ilustrar la política de una tienda en
cuanto al pago de los clientes con
cuatro conjuntos de reglas y cuatro
posibles acciones.
eso es sólo una coincidencia. El siguiente ejemplo demuestra que con frecuencia las tablas de decisión se hacen
extensas y complicadas.
Desarrollar tablas de decisión
Para construir tablas de decisión, el analista necesita determinar el tamaño máximo de la tabla; eliminar cual-
quier situación imposible, inconsistencia o redundancia, y simplificar la tabla lo más que pueda. Los siguientes
pasos proveen al analista un método esquemático para desarrollar tablas de decisión:
1. Determinar el número de condiciones que pueden afectar la decisión. Combinar filas que se traslapan, como
las condiciones mutuamente excluyentes. El número de condiciones se convierte en el número de filas en la
mitad superior de la tabla de decisión.
IF N (la venta total NO es menor de $50.00)
AND
IF Y (el cliente pagó con cheque y tuvo dos formas de ID)
AND
IF N (el cliente no usó una tarjeta de crédito)
THEN
DO X (llamar al supervisor para la aprobación).www.xlibros.com

268 PARTE III • EL PROCESO DE ANÁLISIS
2. Determinar el número de acciones posibles que se pueden realizar. Ese número se convierte en el número de
filas en la mitad inferior de la tabla de decisión.
3. Determinar el número de alternativas de condiciones para cada condición. En la forma más simple de la
tabla de decisión, habría dos alternativas (Y o N) para cada condición. En una tabla con entradas extendidas,
podría haber muchas alternativas para cada condición. Asegúrese de incluir todos los valores posibles para la
condición. Por ejemplo, si el enunciado de un problema que calcule el descuento de un cliente menciona un
rango de valores para un total del pedido de $100 a $1,000 y otro rango de más de $1,000, el analista debe
tener en cuenta que también debe agregar el rango de 0 a $100 como una condición. Esto es cierto sobre
todo cuando hay otras condiciones que se pueden aplicar al total de pedido de 0 a $100.
4. Calcular el número máximo de columnas en la tabla de decisión, para lo cual hay que multiplicar el número
de alternativas para cada condición. Si hubiera cuatro condiciones y dos alternativas (Y o N) para cada una de
las condiciones, habría 16 posibilidades, como se muestra a continuación:
Condición 1: 2 alternativas
Condición 2: 2 alternativas
Condición 3: 2 alternativas
Condición 4: 2 alternativas
16 posibilidades
5. Llenar las alternativas de condiciones. Empezar con la primera condición y dividir el número de columnas
entre el número de alternativas para esa condición. En el ejemplo anterior hay 16 columnas y dos
alternativas (Y o N), por lo que 16 dividido entre 2 es 8. Después hay que elegir una de las alternativas, por
ejemplo Y, y escribirla en las primeras ocho columnas; para terminar hay que escribir N en las ocho
columnas restantes, como se muestra a continuación:
Condición 1: Y Y Y Y Y Y Y Y N N N N N N N N
Condición 1: Y Y Y Y Y Y Y Y N N N N N N N N
Condición 2: Y Y Y Y N N N N
Condición 3: Y Y N N
Condición 4: Y N
Condición 1: Y Y
Condición 2: Y N
Acción 1: X X
6. Para completar la tabla, inserte una X donde las reglas sugieran ciertas acciones.
7. Combine las reglas en las que sea aparente que una alternativa no marca una diferencia en el resultado. Por
ejemplo,
Repita este paso para cada condición; utilice un subconjunto de la tabla,
y continúe el patrón para cada condición:
Condición 1 Y Y Y Y Y Y Y Y N N N N N N N N
Condición 2: Y Y Y Y N N N N Y Y Y Y N N N N
Condición 3: Y Y N N Y Y N N Y Y N N Y Y N N
Condición 4: Y N Y N Y N Y N Y N Y N Y N Y N
se puede expresar como:
Condición 1: Y
Condición 2: —
Acción 1: X
El guión [—] significa que la Condición 2 puede ser Y o N, y la acción se realizará de cualquier manera.
8. Revise cualquier situación imposible, contradicción o redundancia en la tabla. Abundaremos sobre esto
posteriormente.
9. Vuelva a ordenar las condiciones y acciones (o incluso las reglas) si esto le ayuda a comprender mejor la
tabla de decisión.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 269
O P O R T U N I D A D D E C O N S U L T O R Í A 9 . 3
Ahorrar un centavo en Citron Car Rental
“Nos sentimos afortunados de ser tan populares. Creo que los
clientes sienten que tenemos tantas opciones que ofrecerles que
deberían de rentar un automóvil de nosotros”, dice Ricardo Limon,
quien dirige varios puntos de venta para Citron Car Rental. “Nues-
tro eslogan es, ‘Nunca se sentirá exprimido en Citron’. Tenemos
cinco tamaños de automóviles que listamos de la A a la E.”
si su empresa tiene una cuenta con nosotros. También hay un des-
cuento por membresía en cualquiera de los clubes de viajero fre-
cuente operados por las aerolíneas corporativas. Cuando los clientes
se acercan al mostrador, nos dicen el tamaño de automóvil que re-
servaron y verificamos que lo tengamos disponible, listo para irse.
Por lo general preguntan por los descuentos, y nosotros les pregun-
tamos si desean un seguro y cuánto tiempo usarán el automóvil.
Después calculamos su tarifa y les damos un recibo para que lo
firmen ahí mismo”.
Ricardo le ha pedido a usted que computarice el proceso de
facturación para Citron, de manera que los clientes puedan recibir sus
automóviles con rapidez sin errores de facturación. Dibuje una tabla
de decisión que represente las condiciones, alternativas de condicio-
nes, acciones y reglas de acciones que usted deduzca de la narrativa
de Ricardo para guiar un proceso de facturación automatizado.
Ricardo desea expandir la porción de comercio electrónico de
su empresa al hacer que sea posible reservar un automóvil a través
del sitio Web. Dibuje una tabla de decisión actualizada que muestre
un 10 por ciento de descuento por reservar un auto a través del sitio
Web.
A Subcompacto
B Compacto
C Mediano
D Grande
E De lujo
“La transmisión estándar sólo está disponible para A, B y C. La
transmisión automática está disponible para todos los automóviles”.
Si un cliente reserva un subcompacto (A) y al llegar descubre
que no tenemos uno, recibe una actualización gratuita al siguiente
tamaño, en este caso un compacto (B). Los clientes también reciben
una actualización del tamaño de automóviles que tengan reservado
UN EJEMPLO DE TABLA DE DECISIÓN La figura 9.9 es una ilustración de una tabla de decisión desarrollada
mediante el uso de los pasos antes descritos. En este ejemplo, una empresa trata de mantener una lista de clientes
de correo representativa. El objetivo es enviar sólo los catálogos para que los clientes compren la mercancía
anunciada en ellos.
Los gerentes saben que ciertos clientes leales hacen pedidos de todos los catálogos y que algunas personas de
la lista nunca hacen pedidos. Estos patrones de pedidos son fáciles de observar, pero es más difícil decidir cuáles
catálogos enviar a los clientes que ordenan sólo de ciertos catálogos seleccionados. Una vez tomadas estas deci-
siones, se construye una tabla de decisión para tres condiciones (C1: el cliente hizo un pedido del catálogo de
otoño; C2: el cliente hizo un pedido del catálogo de Navidad y C3: el cliente hizo un pedido de un catálogo es-
pecializado), cada una de las cuales tiene dos alternativas (Y o N). Se pueden tomar tres acciones (A1: enviar el
catálogo de Navidad de este año; A2: enviar el nuevo catálogo especializado y A3: enviar ambos catálogos).
La tabla de decisión resultante tiene seis filas (tres condiciones y tres acciones) y ocho columnas (dos alternati-
vas dos alternativas dos alternativas).
Ahora hay que examinar la tabla de decisión para ver si se puede reducir. No hay condiciones mutuamente
excluyentes, por lo que no es posible usar menos de tres filas de condiciones. No hay reglas que permitan la
Condiciones y acciones
El cliente hizo un pedido del catálogo de otoño.
El cliente hizo un pedido del catálogo de Navidad.
El cliente hizo un pedido del catálogo especializado.
Enviar el catálogo de Navidad de este año.
Enviar el catálogo especializado.
Enviar ambos catálogos.
Reglas
1 2 3 4 5 6 7 8
Y Y Y Y N N N N
Y Y N N Y Y N N
Y N
X
X
X X
X
X X X
Y N Y N Y N
FIGURA 9.9
Construcción de una tabla de
decisión para decidir qué catálogo
enviar a los clientes que piden sólo
de catálogos seleccionados.www.xlibros.com

270 PARTE III • EL PROCESO DE ANÁLISIS
combinación de acciones. Sin embargo, es posible combinar algunas de las reglas como se muestra en la figura
9.10. Por ejemplo, las reglas 2, 4, 6 y 8 se pueden combinar debido a que todas tienen dos cosas en común:
1. Nos sugieren enviar el catálogo de Navidad de este año.
2. La alternativa para la Condición 3 siempre es N.
No importa cuáles sean las alternativas para las primeras dos condiciones, por lo que es posible insertar guiones
[—] en vez de Y o N.
Las reglas restantes (1, 3, 5 y 7) no se pueden reducir a una sola regla debido a que restan dos acciones. En
vez de ello podemos combinar las reglas 1 y 5; de igual forma podemos combinar las reglas 3 y 7.
Verificar la integridad y precisión
Es esencial que verifique la integridad y precisión de sus tablas de decisión. Pueden ocurrir cuatro problemas
principales al desarrollar tablas de decisión: que estén incompletas, que existan situaciones imposibles, contra-
dicciones y redundancia.
Es de suma importancia poder asegurar que todas las condiciones, alternativas de condiciones, acciones y re-
glas de acción estén completas. Suponga que omitimos una condición importante (si un cliente hizo un pedido me-
nor de $50) del problema de la tienda de catálogos que vimos antes. Esto provocaría que cambiara toda la tabla de
decisión, ya que habría que agregar una nueva condición, un nuevo conjunto de alternativas, una nueva acción y una
o más nuevas reglas de acción. Suponga que la regla es: SI el cliente no ordenó más de $50, ENTONCES no enviar
catálogos. Se agregaría una nueva regla 4 a la tabla de decisión, como se muestra en la figura 9.11.
Condiciones y acciones
Condiciones y acciones
Reglas
Reglas
El cliente hizo un pedido del catálogo de otoño.
El cliente hizo un pedido del catálogo de Navidad.
El cliente hizo un pedido del catálogo especializado.
Enviar el catálogo de Navidad de este año.
Enviar el catálogo especializado.
Enviar ambos catálogos.
El cliente hizo un pedido del catálogo de otoño.
El cliente hizo un pedido del catálogo de Navidad.
El cliente hizo un pedido del catálogo especializado.
Enviar el catálogo de Navidad de este año.
Enviar el catálogo especializado.
Enviar ambos catálogos.
Y
Y
Y
Y
Y Y
Y
Y
Y
Y
Y
Y
Y
Y Y
N
N N
N
N N
N
N
N
N
N
N
N
N
X
X
X
X
X
X
X
X
X
X
X
1 2 3 4 5 6 7 8
1' 2' 3'
FIGURA 9.10
Combinación de reglas para
simplificar la tabla de decisión
cliente-catálogo.
Condiciones y acciones
Reglas
El cliente hizo un pedido del catálogo de otoño.
El cliente hizo un pedido del catálogo de Navidad.
El cliente hizo un pedido del catálogo especializado.
El cliente hizo un pedido de $50 o más.
Enviar el catálogo de Navidad de este año.
Enviar el catálogo especializado.
Enviar ambos catálogos.
No enviar ningún catálogo.
Y
Y
Y Y
Y
Y
N
N
N
X
X
X
X
1' 2' 3' 4'
FIGURA 9.11
Al agregar una regla a la tabla de
decisión cliente-catálogo se
modifica toda la tabla.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 271
Al construir tablas de decisión según lo indicado en los pasos anteriores, algunas veces podemos llegar a
establecer situaciones imposibles. En la figura 9.12 se muestra un ejemplo. La regla 1 no es factible, ya que una
persona no puede obtener más de $50,000 al año y menos de $2,000 mensuales por mes al mismo tiempo. Las
otras tres reglas son válidas. El problema pasó desapercibido debido a que la primera condición se midió en años
y la segunda en meses.
Cuando las reglas sugieren distintas acciones pero satisfacen las mismas condiciones, ocurren contradic-
ciones. La falla podría estar en la forma en que el analista construyó la tabla o en la información que recibió.
A menudo ocurren contradicciones si se insertan guiones [—] incorrectamente en la tabla. La redundancia ocu-
rre cuando conjuntos idénticos de alternativas requieren exactamente la misma acción. La figura 9.13 ilustra una
contradicción y una redundancia. El analista debe determinar qué es lo correcto y después resolver la contradic-
ción o redundancia.
Las tablas de decisión son una importante herramienta en el análisis de las decisiones estructuradas. Una
ventaja importante de usar tablas de decisión en comparación con otros métodos es que las tablas ayudan al ana-
lista a asegurar la integridad. Al usar tablas de decisión también se facilita la acción de verificar posibles errores,
como las situaciones imposibles, contradicciones y redundancia. También existen los procesadores de tablas de
decisión, que reciben la tabla como entrada y proveen código de programa de computadora como salida.
ÁRBOLES DE DECISIÓN
Los árboles de decisión se utilizan cuando ocurren ramificaciones complejas en un proceso de decisión estruc-
turado. Los árboles también son útiles cuando es imprescindible mantener una cadena de decisiones en una
secuencia específica. Aunque el nombre “árbol de decisión” se deriva de los árboles naturales, por lo general
los árboles de decisión se dibujan de lado, con la raíz en el lado izquierdo del papel; a partir de ahí el árbol
se ramifica hacia la derecha. Esta orientación permite al analista escribir en las ramas para describir las con-
diciones y acciones.
A diferencia del árbol de decisión que se utiliza en la ciencia de la administración, el árbol del analista no
contiene probabilidades y resultados. En el análisis de sistemas, los árboles se utilizan principalmente para iden-
tificar y organizar las condiciones y acciones en un proceso de decisión completamente estructurado.
Condiciones y acciones
Salario > $50,000/año
Salario < $2,000/mes
Acción 1
Acción 2
Reglas
1 2 3 4
Y Y N N
Y N Y N
Ésta es una
situación
imposible.
FIGURA 9.12
Es importante verificar que la
tabla de decisión no tenga
situaciones imposibles.
Condiciones y acciones
Reglas
Y
Y Y
Y Y
Y
Y
Y
YN
N
N
N
N
N
X
X
X
X X
X
X
1 2 3 4 5 6 7
Y
N
Condición 1
Condición 2
Condición 3
Acción 1
Acción 2
Acción 3
Contradicción Redundancia
FIGURA 9.13
Es importante verificar que la
tabla de decisión no tenga
contradicciones ni redundancia
inadvertidas.www.xlibros.com

272 PARTE III • EL PROCESO DE ANÁLISIS
Dibujar árboles de decisión
Es conveniente poder diferenciar entre las condiciones y las acciones al momento de dibujar árboles de decisión.
Esta distinción es en especial relevante cuando las condiciones y acciones se llevan a cabo durante un periodo de
tiempo y su secuencia es importante. Para este fin hay que utilizar un nodo cuadrado para indicar una acción y
un círculo para representar una condición. El uso de esta notación mejora la legibilidad del árbol, al igual que la
acción de enumerar los círculos y cuadrados en forma secuencial. Piense en un círculo como si fuera un SI (IF),
mientras que el cuadrado significa ENTONCES (THEN).
Cuando hablamos sobre las tablas de decisión en una sección anterior, utilizamos un ejemplo de punto de venta
para determinar las acciones para aprobar las compras en una tienda de departamentos. Las condiciones incluían el
monto de la venta (menor a $50) y si el cliente pagaba con cheque o tarjeta de crédito. Las cuatro acciones posibles
eran completar la venta después de verificar la firma; completar la venta sin necesidad de la firma; llamar al super-
visor para la aprobación, o comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito. La
figura 9.14 muestra cómo se puede dibujar este ejemplo como un árbol de decisión. Al dibujar el árbol hay que:
1. Identificar todas las condiciones y acciones, junto con su orden y sincronización (si son críticas).
2. Empezar a construir el árbol de izquierda a derecha; hay que asegurarnos de enlistar todas las alternativas
posibles antes de avanzar a la derecha.
El árbol simple es simétrico y las cuatro acciones al final son únicas, aunque un árbol no tiene que ser simétrico.
La mayoría de los árboles de decisión tienen condiciones con un número distinto de ramificaciones. Además
pueden aparecer acciones idénticas más de una vez.
O P O R T U N I D A D D E C O N S U L T O R Í A 9 . 4
Un árbol gratis
“sé que debe abordar un avión, pero déjeme tratar de expli-
carle otra vez, señor”, suplica Glen Curtis, gerente de marketing
de Premium Airlines. Curtis ha estado tratando, sin éxito, de ex-
plicar la nueva política de la aerolínea para acumular millas y
obtener premios (como promociones a primera clase y vuelos
gratis) para los miembros del club “Volando por premios” de
Premium Airlines.
Glen hace otro intento por echar a volar la política, y dice:
“Mire, señor, el viajero (ése es usted, el Sr. Icarus) recibirá las mi-
llas que haya volado. Si la distancia recorrida de un tramo fue me-
nor a 500 millas, el viajero recibirá 500 millas de crédito. Si el viaje
se hizo en sábado, la distancia recorrida se multiplicará por dos. Si
el viaje se hizo en martes, el factor de multiplicación es de 1.5. Si éste
es el noveno tramo recorrido durante el mes calendario, las millas
se duplican sin importar cuál sea el día, y si es el 17° tramo reco-
rrido, se triplican las millas. Si el viajero reservó el vuelo a través
de Web o mediante un servicio de viajes como Orbiz o Travelocity,
se agregan 100 millas”.
“Espero que ahora le quede más claro, Sr. Icarus. Disfrute su
vuelo y gracias por volar en Premium”.
El Sr. Icarus, cuyo deseo de abordar el avión de Premium es-
tuvo a punto de desaparecer durante la extensa explicación de Glen,
se pierde en el mar de personas que caminan por las filas de seguri-
dad, sin emitir siquiera un sonido en respuesta.
Desarrolle un árbol de decisión para la nueva política de Pre-
mium Airlines sobre la forma de acumular millas, de manera que la
política sea más clara, más fácil de comprender en forma visual y,
por ende, más fácil de explicar.
Completar la venta después de verificar la firma.
Cheque
Tarjeta de crédito
Cheque
Menos de $50
≥ $50
Tarjeta de crédito
Completar la venta. No se requiere firma.
Llamar al supervisor para la aprobación.
Comunicarse vía electrónica con el banco para
la autorización de la tarjeta de crédito.
2
5
7
6
4
3
1
FIGURA 9.14
Cómo dibujar un árbol de decisión
para mostrar las acciones de
aprobación de compras que no son
en efectivo para una tienda
departamental.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 273
El árbol de decisión tiene tres principales ventajas sobre una tabla de decisión. En primer lugar saca prove-
cho de la estructura secuencial de sus ramas, por lo que se puede observar de inmediato el orden de verificación
de las condiciones y ejecución de las acciones. En segundo lugar, podemos encontrar condiciones y acciones de
los árboles de decisión en algunas ramas pero no en otras, lo cual contrasta con las tablas de decisión, donde to-
das forman parte de la misma tabla. Esas condiciones y acciones que son críticas se conectan de manera directa
con otras condiciones y acciones, mientras que las condiciones que no importan están ausentes. En otras pala-
bras, el árbol no tiene que ser simétrico. En tercer lugar, en comparación con las tablas de decisión, otras perso-
nas en la organización pueden comprender con más facilidad los árboles de decisión. En consecuencia, son más
apropiados como herramienta de comunicación.
CÓMO ELEGIR UNA TÉCNICA DE ANÁLISIS DE DECISIONES ESTRUCTURADAS
Ya examinamos las tres técnicas de análisis de decisiones estructuradas: español estructurado, tablas de decisión
y árboles de decisión. Aunque no es necesario utilizarlas en forma exclusiva, es costumbre elegir una técnica de
análisis para una decisión en vez de emplear las tres. Los siguientes lineamientos le proveerán una manera de elegir
una de las tres técnicas para un caso específico:
1. Use español estructurado cuando
a. Haya muchas acciones repetitivas,
O
b. La comunicación con los usuarios finales sea importante.
2. Use tablas de decisión cuando
a. Se encuentre con combinaciones complejas de condiciones, acciones y reglas,
O
b. Requiera un método que evite de manera efectiva las situaciones imposibles, redundancias y
contradicciones.
3. Use los árboles de decisión cuando
a. La secuencia de condiciones y acciones sea crítica,
O
b. No todas las condiciones sean relevantes para todas las acciones (que las ramificaciones sean distintas).
RESUMEN
Una vez que el analista trabaja con los usuarios para identificar
los flujos de datos y empieza a construir un diccionario de datos,
es tiempo de pasar a la especificación de procesos y el análisis de
decisiones. Los tres métodos para el análisis de decisiones y para
describir la lógica de procesos que vimos en este capítulo son
español estructurado, tablas de decisión y árboles de decisión.
Las especificaciones (o mini-especificaciones) de procesos
se crean para los procesos primitivos en un diagrama de flujo
de datos, así como para algunos procesos de nivel más alto
que se expanden en un diagrama hijo. Estas especificaciones
explican la lógica de toma de decisiones y las fórmulas que
transformarán los datos de entrada de un proceso en su salida.
Los tres objetivos de la especificación de procesos son reducir
la ambigüedad del proceso, obtener una descripción precisa de
lo que se logra y validar el diseño del sistema.
Una manera de describir las decisiones estructuradas es me-
diante el método que se conoce como español estructurado, en
el cual la lógica se expresa en estructuras secuenciales, estruc-
turas de decisión, estructuras de casos o iteraciones. El español
estructurado utiliza palabras clave aceptadas tales como SI (IF),
ENTONCES (THEN), SINO (ELSE), HACER (DO), HACER
MIENTRAS (DO WHILE) y HACER HASTA (DO UNTIL)
para describir la lógica utilizada; además hace uso de la sangría para
indicar la estructura jerárquica del proceso de decisión.
Las tablas de decisión son otra forma de examinar, describir
y documentar las decisiones. Se utilizan cuatro cuadrantes (que se
ven en sentido de las manecillas del reloj, a partir de la esquina
superior izquierda) para: 1) describir las condiciones, 2) identificar
las posibles alternativas de decisión (como Y o N), 3) indicar qué
acciones se deben realizar y 4) describir las acciones. Las tablas
de decisión son ventajosas ya que las reglas para desarrollar la
tabla en sí, además de las reglas para eliminar redundancia, con-
tradicciones y situaciones imposibles, son simples y manejables.
Al usar tablas de decisión se fomenta la integridad y precisión en
el análisis de las decisiones estructuradas.
El tercer método para el análisis de decisiones es el árbol
de decisión, que consiste en nodos (un cuadrado para las accio-
nes y un círculo para las condiciones) y ramificaciones. Los ár-
boles de decisión son apropiados cuando las acciones se deben
llevar a cabo en cierta secuencia. No hay ningún requerimiento
de que el árbol sea simétrico, por lo que sólo las condiciones y
acciones que sean críticas para las decisiones en cuestión son
las que se encuentran en una rama específica.
Cada uno de los métodos de análisis de decisiones tiene
sus propias ventajas y se debe utilizar de manera acorde. El es-
pañol estructurado es muy útil cuando se repiten muchas accio-
nes y cuando es importante comunicarse con otros. Las tablas
de decisión proveen un análisis completo de las situaciones
complejas, al tiempo que limitan la necesidad de cambio que
se atribuye a las situaciones imposibles, redundancias o contra-
dicciones. Los árboles de decisión son importantes cuando es
imprescindible la secuencia apropiada de las condiciones y ac-
ciones, y cuando cada una de las condiciones no son relevantes
para cada una de las acciones.www.xlibros.com

274 PARTE III • EL PROCESO DE ANÁLISIS
E X P E R I E N C I A D E H Y P E R C A S E ® 9
“Es realmente grandioso que hayas podido pasar todo este
tiempo con nosotros: es un hecho que toda ayuda nos es de gran
utilidad. Y sin duda, después de haber conversado con Snowden y
los demás, usted debe tener claro que todos creemos que los consul-
tores desempeñan un papel importante para ayudar a las empresas
a cambiar. Bueno, al menos la mayoría de nosotros lo creemos”.
“Algunas veces la estructura es buena para una persona. O in-
cluso para una empresa. Como sabe, Snowden se interesa en cual-
quier tipo de estructura. Ésa es la razón por la que algunas personas
de Capacitación lo vuelven loco algunas veces. Son buenos al es-
tructurar cosas para sus clientes, pero cuando se trata de organizar
su propio trabajo, es otro cuento. Pero bueno, avíseme si hay algo
que pueda hacer por usted”.
Pregunta de HYPERCASE
1. Suponga que va a crear las especificaciones para un sistema
de rastreo de proyectos automatizado para los empleados de
Capacitación. Una de las funciones del sistema será permitir
que los miembros actualicen o agreguen nombres,
direcciones y números de teléfono/fax de los nuevos clientes.
Use el español estructurado para escribir un procedimiento
en el que se lleve a cabo el proceso de introducir el nombre
de un nuevo cliente, su dirección y número telefónico/de fax.
[Sugerencia: El procedimiento debe pedir el nombre de
un cliente, verificar si el nombre ya existe en un archivo
de clientes y permitir que el usuario valide y actualice la
dirección y número de teléfono/fax actual del cliente (si es
necesario), o agregar la dirección y el número de teléfono/fax
de un nuevo cliente al archivo de clientes].
PALABRAS CLAVE Y FRASES
acción
alternativa de condición
árbol de decisión
condición
decisión estructurada
español estructurado
especificaciones de procesos
mini-especificaciones
regla de acción
tabla de decisión
PREGUNTAS DE REPASO
1. Elabore una lista de tres razones para producir las especificaciones de los procesos.
2. Defina lo que significa una decisión estructurada.
3. ¿Cuáles son los cuatro elementos que debe conocer el analista de sistemas para diseñar los sistemas teniendo en cuenta
las decisiones estructuradas?
4. ¿Cuáles son los dos bloques de construcción del español estructurado?
5. Mencione cinco convenciones a seguir cuando se utiliza español estructurado.
6. ¿Cuál es la ventaja de usar español estructurado para comunicarse con las personas en la organización?
7. ¿Cuál cuadrante de la tabla de decisión se utiliza para las condiciones? ¿Cuál se usa para las alternativas de condiciones?
8. ¿Cuál es el primer paso a seguir en el desarrollo de una tabla de decisión?
9. Mencione los cuatro problemas principales que pueden ocurrir al desarrollar tablas de decisión.
10. ¿Cuál es una de las principales ventajas de las tablas de decisión si se les compara con otros métodos de análisis de
decisiones?
11. ¿Cuáles son los principales usos de los árboles de decisión en el análisis de sistemas?
12. Mencione los cuatro pasos principales para construir árboles de decisión.
13. ¿Cuáles son las tres ventajas que tienen los árboles de decisión sobre las tablas de decisión?
14. ¿Cuáles son las dos situaciones en las que debemos usar español estructurado?
15. ¿Cuáles son las dos situaciones en las que funcionan mejor las tablas de decisión?
16. ¿Cuáles son las dos situaciones en las que es preferible usar árboles de decisión?
PROBLEMAS
1. Clyde Clerk está revisando las políticas de reembolso de gastos de su empresa con el nuevo vendedor, Trav Farr.
“Nuestras políticas de reembolso dependen de la situación. Verás, primero determinamos si es un viaje local. Si es así,
sólo pagamos la distancia recorrida a 18.5 centavos por milla. Si el viaje fue de un día, pagamos la distancia recorrida ywww.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 275
después revisamos las horas de salida y retorno. Para que puedas obtener un reembolso para el desayuno, debes salir a
las 7:00 AM, almorzar antes de las 11:00 A.M. y comer antes de las 5:00 P.M. Para recibir el reembolso para el
desayuno, debes regresar después de las 10:00 A.M., almorzar después de las 2:00 P.M. y comer antes de las 7:00 P.M.
En un viaje que dure más de un día, otorgamos viáticos para hotel, taxi y tarifas de avión, así como las comidas. Se
aplican los mismos horarios para los gastos de comida”. Escriba en español estructurado la narrativa de Clyde sobre las
políticas de reembolso.
2. Dibuje un árbol de decisión que describa la política de reembolso del problema 1.
3. Dibuje una tabla de decisión que describa la política de reembolso del problema 1.
4. Una empresa de provisiones para computadoras conocida como True Disk acaba de establecer cuentas para
innumerables negocios en Dosville. True Disk envía las facturas cada mes y ofrece descuentos si los pagos se realizan
dentro de un plazo de 10 días. La política de descuento es la siguiente: si el monto del pedido de provisiones de
computadoras es mayor de $1,000, restar un 4 por ciento al pedido; si el monto está entre $500 y $1,000, restar un 2 por
ciento de descuento; si el monto es menor de $500, no aplicar ningún descuento. Todos los pedidos realizados a través
del sitio Web reciben de manera automática un descuento adicional del 5 por ciento. Cualquier pedido especial (muebles
para computadoras, por ejemplo) está exento de los descuentos.
Desarrolle una tabla de decisiones para las decisiones sobre los descuentos de True Disk, en donde las alternativas
de las condiciones se limiten a Y y N.
5. Desarrolle una tabla de decisión con entradas extendidas para la política de descuentos de la empresa True Disk del
problema 4.
6. Desarrolle un árbol de decisión para la póliza de descuentos de la empresa True Disk del problema 4.
7. Escriba español estructurado para resolver la situación de la empresa True Disk del problema 4.
8. Premium Airlines ofreció recientemente llegar a un acuerdo sobre una demanda colectiva que se originó debido a un
supuesto acuerdo de precios de los boletos. El acuerdo propuesto se establece de la siguiente manera:
Al inicio, Premium Airlines pondrá a disposición del acuerdo colectivo un fondo principal de $25 millones en cupones.
Si el número de demandas válidas interpuestas es de 1.25 millones o menos, el valor de cada demanda será el resultado
que se obtiene al dividir $25 millones entre el número total de demandas válidas que se hayan interpuesto. Por ejemplo,
si hay 500,000 demandas válidas, cada persona que haya interpuesto una demanda válida recibirá un cupón con un valor
de $50.
La denominación de cada cupón que se distribuya será en dólares sin centavos, y no deberá exceder a $50. Por
ende, si hay menos de 500,000 demandas válidas, el valor de cada demanda se dividirá entre dos o más cupones. Por
ejemplo, si hay 250,000 demandas válidas, cada persona que haya interpuesto una demanda válida recibirá dos cupones,
cada uno de los cuales tendrá un valor nominal de $50, para un valor total de cupones de $100.
Si el número de demandas válidas interpuestas está entre 1.25 millones y 1.5 millones, Premium Airlines hará
disponible un fondo complementario de cupones, con un valor potencial de $5 millones. El fondo complementario
estará disponible según sea necesario para proveer un cupón de $20 por cada demanda válida.
Si hay más de 1.5 millones de demandas válidas, el monto total del fondo principal y el fondo complementario, que
en conjunto equivalen a $30 millones, se dividirá en forma equitativa para producir un cupón para cada demanda válida.
El valor de cada uno de esos cupones será de $30 millones divididos entre el número total de demandas válidas.
Dibuje un árbol de decisión para el acuerdo de Premium Airlines.
9. Escriba español estructurado para el acuerdo de Premium Airlines del problema 8.
10. “Bueno, es algo difícil de describir”, dice Sharon, consejera del centro de nutrición Less Is More. “En realidad nunca he
tenido que decirle a nadie sobre la forma en que cobramos a los clientes, pero voy a intentarlo”.
“Cuando los clientes entran a Less Is More, verificamos si ya habían usado nuestros servicios antes. Por desgracia
para ellos, creo, tenemos muchos clientes repetidos que siguen rebotando. Los clientes repetidos obtienen una tarifa
reducida (perdón por el juego de palabras) de $100 por la primera visita, si regresan dentro de un periodo menor a 1 año
de haber finalizado su programa”.
“Todos los de nuevo ingreso pagan una cuota inicial de $200 para una evaluación física. El cliente puede traer un
cupón en ese momento y nosotros deducimos $50 de la cuota de inscripción. La mitad de nuestros clientes utilizan
nuestros cupones y se enteran sobre nosotros gracias a éstos. Pero nuestros clientes repetidos sólo obtienen el descuento
de $100; ¡No pueden usar un cupón también! Los clientes que se transfieren de uno de nuestros centros en otra ciudad
reciben $75 de descuento de su primer pago, pero el cupón no es válido. Los clientes que pagan en efectivo reciben un
10 por ciento de descuento de los $200, pero no pueden usar un cupón aparte de eso”.
Cree una tabla de decisión con condiciones Y o N para el sistema de cobro para los clientes del centro de nutrición
Less Is More.
11. Reduzca la tabla de decisión de la figura 9.EJ1 al número mínimo de reglas.
12. Azure Isle Resort tiene una estructura de precios para vacacionistas en una de sus tres categorías de habitaciones: el
hotel, las villas y los chalets de playa. El precio base es por quedarse en el hotel. Los chalets de playa tienen un recargo
del 10 por ciento y la renta de una villa tiene un recargo del 15 por ciento. El precio final incluye un descuento del 4 por
ciento para los clientes frecuentes. Las demás condiciones se aplican a qué tan cerca está el centro vacacional de llenarse
a toda su capacidad y si la fecha solicitada está dentro del periodo de un mes a partir de la fecha actual. Si el centro
vacacional está lleno al 50 por ciento y la fecha está dentro del periodo de un mes, hay un 12 por ciento de descuento. Siwww.xlibros.com

276 PARTE III • EL PROCESO DE ANÁLISIS
Reglas
Cantidad suficiente disponible
Cantidad lo bastante grande
como para el descuento
Cliente de mayoreo
Se presentó exención de
impuestos sobre venta
Enviar artículos y preparar
factura
Preparar pedido de artículos
pendientes
Deducir descuento
Agregar impuestos sobre venta
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
X
Y Y Y Y Y Y Y Y N N N N N N N N
Y Y Y Y N N N N Y Y Y Y NN N N
Y Y N N Y Y N N Y Y N N Y Y N N
Y N Y N Y N Y N Y N Y N Y N Y N
X
X X
X X X X X X
X X X X X X
X X X X X X X X
Condiciones y acciones
FIGURA 9.EJ1
Una tabla de decisión para un
almacén.
el centro vacacional está lleno al 70 por ciento y la fecha está dentro del periodo de un mes, hay un 6 por ciento de
descuento. Si el centro vacacional está lleno al 85 por ciento y la fecha está dentro del periodo de un mes, hay un 4 por
ciento de descuento.
Desarrolle una tabla de decisión optimizada para la estructura de precios de Azure Isle Resort.
13. Cree un árbol de decisión para el problema 12.
14. El precio base del boleto para Cloudliner Airlines se determina en base a la distancia recorrida y el día de la semana
en que el pasajero piensa viajar. Además, la aerolínea ajusta los boletos de sus precios con base en varias categorías.
Si los asientos restantes son más del 50 por ciento de la capacidad y el número de días antes del vuelo es menor a 7,
el precio recibe un buen descuento con una oferta Web especial para el vuelo. Si los asientos restantes son mayores al
50 por ciento y la fecha del vuelo es de 7 a 21 días en el futuro, hay un descuento medio en el precio. Si los asientos
restantes son mayores al 50 por ciento y el número de días antes de viajar es mayor de 21, sólo hay un pequeño
descuento.
Si los asientos restantes representan de un 20 a un 50 por ciento de la capacidad y los días antes del vuelo son
menores de 7, el boleto tiene un descuento medio. Si los asientos restantes representan de un 20 a un 50 por ciento de la
capacidad y la fecha del vuelo es de 7 a 21 días en el futuro, hay un descuento bajo en el precio. Si los asientos restantes
representan de un 20 a un 50 por ciento de la capacidad y el número de días antes de viajar es mayor de 21, hay un
pequeño incremento en el precio.
Desarrolle una tabla de decisión optimizada para las políticas de ajuste de precios en los boletos de Cloudliner
Airlines.
15. Desarrolle un árbol de decisión para la situación del problema 14.
PROYECTOS EN GRUPO
1. Cada miembro de grupo (o cada subgrupo) debería optar por convertirse en un “experto” y prepararse para explicar
cómo y cuándo usar una de las siguientes técnicas de decisión estructuradas: español estructurado, tablas de decisión o
árboles de decisión. Después cada miembro del grupo o subgrupo deberán crear un caso en relación con la utilidad de su
técnica de análisis de decisión asignada para estudiar los tipos de decisiones estructuradas tomadas por Maverick
Transport en cuanto a despachar ciertos camiones hacia destinos específicos. Cada grupo debe hacer una presentación de
su técnica preferida.
2. Después de escuchar cada presentación, el grupo debería llegar a un consenso en cuanto a cuál técnica es la más
apropiada para analizar las decisiones de Maverick Transport al despachar los camiones y por qué es mejor esa técnica
en este caso.
BIBLIOGRAFÍA SELECCIONADA
Anderson, D. R., D. J. Sweeny, T. A. Williams y R. K. Martin. An Introduction to Management Science, 10ª. Edición. Florence,
KY: South-Western College Publishing (un sello de Cengage), 2007.
Evans, J. R. Applied Production and Operations Management, 4ª. Edición. St. Paul, MN: West, 1993.www.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 277
E P I S O D I O 9
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Presentar una decisión
Después de realizar muchas entrevistas de seguimiento con Dot Matricks, Anna dice a Chip: “He determinado la lógica nece-
saria para actualizar el almacén de datos PEDIDOS DE COMPUTADORAS PENDIENTES. Como se pueden pedir muchas
computadoras en la misma orden de compra, a medida que se introduce cada computadora se localiza el registro que coincida
y se resta uno al número de computadoras pendientes por cada orden de compra”.
Anna muestra a Chip la impresión de la pantalla del repositorio Process (Proceso). “El nombre del proceso correspon-
diente, ACTUALIZAR PEDIDO DE COMPUTADORAS PENDIENTES (proceso 2.5), vincula la especificación del proceso
con el diagrama de flujo de datos”, explica ella. Se listan las entradas y salidas; además deben coincidir con el flujo de datos
que entra o sale del proceso. “El registro TRANSACCIÓN DE COMPUTADORA VÁLIDA es entrada y el PEDIDO PEN-
DIENTE actualizado es el flujo de salida”.
“Eso será útil”, dice Chip, “incluso si nos lleva tiempo desenmarañarlo todo”.
Anna señala: “El área Process Description (Descripción del proceso) contiene la lógica, la cual se muestra en español
estructurado”.
Una vez completa la lógica, Anna introduce unas cuantas notas más sobre la naturaleza del proceso, agrega la observación
de que es un proceso por lotes y también agrega información de sincronización.
Se puede crear una tabla de decisión para la lógica de control o de proceso. Antes de teclear la tabla de decisión, sería
conveniente crearla en papel y optimizarla. De esta forma se introducirán sólo las condiciones y acciones esenciales.
“Yo también he estado ocupado”, Chip asegura a Anna. “Hablé con Cher Ware varias veces después desde que tú la entre-
vistaste. Por fin capturé parte de la lógica para calcular el costo de una actualización de software”.
“Cher indicó tres condiciones diferentes que afectan en el costo. La licencia del sitio provee copias ilimitadas y se utiliza
para el software popular instalado en muchas computadoras. Muchos editores proveen un descuento académico y también hay
por lo general un descuento por cantidad disponible”, continúa.
“Primero determiné los valores para las condiciones y el número de combinaciones”, dice Chip. Él estableció las tres
condiciones y sus valores de la siguiente manera:
“El número total de combinaciones se obtiene al multiplicar el número de valores para cada una de las condiciones, 2 2
2 8. El siguiente paso es decidir qué condiciones deben ser primero”. Chip continúa: “Deduzco que una licencia de sitio
no tendría un descuento por cantidad o un descuento académico adicional, ya que el costo de la licencia de sitio refleja de an-
temano este tipo de descuento. Por lo tanto, LICENCIA DE SITIO debería ser la primera condición. Cada una de las otras dos
condiciones no tendrían una ventaja específica sobre la otra, por lo que no importa su orden.
“Como el número total de condiciones es de ocho y la condición LICENCIA DE SITIO tiene dos posibles valores, el
factor de repetición sería de 8/2 o 4”. Chip continúa y deja establecido que la primera fila de la tabla de decisión sería:
“La siguiente condición es DESCUENTO ACADÉMICO, que también tiene dos valores. Al dividir el factor anterior de
cuatro entre estos dos valores obtenemos 4/2 = 2 para el siguiente factor de repetición”. Chip observa que la tabla de decisión
ahora se expande en lo siguiente:
Condición Valores Número de valores
LICENCIA DE SITIO Y/N 2
DESCUENTO ACADÉMICO Y/N 2
DESCUENTO POR CANTIDAD Y/N 2
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
DESCUENTO ACADÉMICO Y Y N N Y Y N Nwww.xlibros.com

278 PARTE III • EL PROCESO DE ANÁLISIS
Chip continúa: “La última condición, DESCUENTO POR CANTIDAD, también tiene dos valores; al dividir el factor de
repetición anterior de dos entre estos dos valores obtenemos 2/2 1, que debe ser siempre el factor de repetición para la última
fila de las condiciones”. Chip deja establecido que la entrada de condiciones completa es:
Chip señala que cuando se incluyen las acciones, la tabla de decisión completa es la siguiente:
“Me puse a reducir algunas de las acciones redundantes, en especial las que ocurren al obtener una licencia de sitio”. Chip
continúa: “Como las acciones son las mismas para los valores de Licencia de sitio de Y, los descuentos académicos y por can-
tidad no significan nada para la condición y no tienen que considerarse. Las reglas 1 a 4 se pueden reducir en una regla”. Chip
concluye con la observación de que la tabla de decisión optimizada es la siguiente:
La tabla de decisión final, que se muestra en la figura 9.1, contiene la tabla de decisión optimizada. Hay tres condiciones:
que haya una licencia de sitio, un descuento académico o un descuento por cantidad. El cuadrante superior izquierdo contiene
las condiciones. Directamente debajo de ellas están las acciones. Las alternativas de condición están en el cuadrante superior
Condiciones y acciones 1 2 3 4 5
Licencia de sitio
Descuento académico
Descuento por cantidad
Y N N N N
Y Y N N
Y N Y N
Costo de actualización = Costo de licencia de sitio
Costo de actualización = Costo académico * Número de copias
Costo de actualización = Costo de descuento * Número de copias
Costo de actualización = Costo por copia * Número de copias
Costo de actualización = (Costo académico – Descuento)
* Número de copias
X
X
X
X
X
FIGURA E9.1
Tabla de decisión, COSTO DE
ACTUALIZACIÓN.
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
DESCUENTO ACADÉMICO Y Y N N Y Y N N
DESCUENTO POR CANTIDAD Y N Y N Y N Y N
Condición 1 2 3 4 5 6 7 8
LICENCIA DE SITIO Y Y Y Y N N N N
DESCUENTO ACADÉMICO Y Y N N Y Y N N
DESCUENTO POR CANTIDAD Y N Y N Y N Y N
Acciones
COSTO COSTO DE LICENCIA DE SITIO
COSTO COSTO ACADÉMICO X COPIAS
COSTO COSTO DESCUENTO X COPIAS
COSTO COSTO ACTUALIZACIÓN X COPIAS
COSTO (COSTO EDUC – DESC) X COPIAS
X X X X
X
X
X
X
Condición 1 2 3 4 5
LICENCIA DE SITIO Y N N N N
DESCUENTO ACADÉMICO — Y Y N N
DESCUENTO POR CANTIDAD — Y N Y N
Acciones
COSTO COSTO DE LICENCIA DE SITIO
COSTO COSTO ACADÉMICO X COPIAS
COSTO COSTO DESCUENTO X COPIAS
COSTO COSTO ACTUALIZACIÓN X COPIAS
COSTO (COSTO EDUC – DESC) X COPIAS
X
X
X
X
Xwww.xlibros.com

CAPÍTULO 9 • ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS 279
derecho y las entradas de acción están en el cuadrante inferior derecho. Las acciones muestran cómo se determina el costo de
actualización para cada condición, lo cual se indica mediante una X en las columnas de las reglas.
EJERCICIOS
Nota: si no utiliza Visible Analyst, puede realizar algunos de los siguientes ejercicios mediante una plantilla de Microsoft Word o Microsoft
Excel para tablas de decisión. El repositorio también está disponible como página Web.
E-1. Use Visible Analyst para ver la entrada en el repositorio del Proceso (Process) para ACTUALIZAR PEDIDO DE COMPU-
TADORAS PENDIENTES (UPDATE PENDING COMPUTER ORDER).
E-2. Use Visible Analyst para modificar e imprimir la entrada del Proceso (Process) SUBTOTALES DE HARDWARE ACUMU-
LATIVOS (ACCUMULATIVE HARDWARE SUBTOTALS). Agregue la Descripción del proceso (Process Descrip-
tion): “Acumular los subtotales de hardware. Estos incluyen el número de máquinas para cada marca de hardware”.
E-3. Use Visible Analyst para modificar e imprimir la entrada del Proceso (Process) CONFIRMAR ELIMINACIÓN DE
COMPUTADORA (CONFIRM COMPUTER DELETION). Agregue la siguiente Descripción del proceso (Process
description):
Usa el REGISTRO DE COMPUTADORA (COMPUTER RECORD) para aplicar formato a la pantalla Confirmación
de eliminación (Deletion Confirmation) (consultar la pantalla Eliminar prototipo de computadora [Delete
Computer Prototype]).
Pedir al usuario que haga clic en el botón OK para confirmar la eliminación; en caso contrario, hacer clic en el botón
Cancelar (Cancel) para cancelar la eliminación.
Si el operador hace clic en OK para eliminar el registro, eliminar el registro y mostrar un mensaje “Se eliminó el
registro”; en caso contrario mostrar un mensaje “Se canceló la eliminación”.
E-4. Crear especificaciones de Proceso (Process) para el proceso 6.6, VALIDAR MODIFICACIONES DE COMPUTA-
DORA (VALIDATE COMPUTER CHANGES). La Descripción del proceso (Process Description) para el proceso es
la siguiente:
Validar las modificaciones en el ARCHIVO MAESTRO DE COMPUTADORA (COMPUTER MASTER). Incluir una nota
para usar los criterios de edición establecidos para cada elemento. Proveer los siguientes criterios de edición adicionales:
La UBICACIÓN DE LA SALA (ROOM UBICATION) debe ser válida para un campus específico.
No debe haber un segundo disco duro sin el primero.
La FECHA DEL ÚLTIMO MANTENIMIENTO PREVENTIVO (LAST PREVENTIVE MAINTENANCE DATE) no
debe ser mayor que la fecha actual.
La FECHA DE COMPRA (DATE PURCHASED) no debe ser mayor que LA FECHA DEL ÚLTIMO
MANTENIMIENTO PREVENTIVO (LAST PREVENTIVE MAINTENANCE DATE) ni mayor que la fecha actual.
El MODELO (MODEL) se debe conformar al tipo soportado por el nombre de MARCA (BRAND).
No se pueden realizar modificaciones en un registro inactivo.
E-5. Cree especificaciones de proceso para el proceso 1.4, CREAR ARCHIVO DE REGISTRO DE SOFTWARE (CREATE
SOFTWARE LOG FILE). Use los ejemplos del diagrama de flujo de datos para determinar las entradas y salidas. Los
detalles del proceso son los siguientes:
Aplicar formato a la ENTRADA EN EL REGISTRO DE SOFTWARE (SOFTWARE LOG RECORD) a partir de la
siguiente información:
Los elementos NUEVO REGISTRO DE SOFTWARE (NEW SOFTWARE RECORD) confirmados.
Los siguientes elementos del sistema: FECHA DEL SISTEMA (SYSTEM DATE), HORA DEL SISTEMA (SYSTEM
TIME), ID DE USUARIO (USER ID).
Cuando se haya aplicado formato al registro, escribir en el ARCHIVO DE REGISTRO DE SOFTWARE (SOFTWARE
LOG FILE).
E-6. Produzca las especificaciones de proceso para el proceso 9.7.2, BUSCAR REGISTRO DE HARDWARE QUE COIN-
CIDA (FIND MATCHING HARDWARE RECORD). Este proceso forma parte de un programa que produce un informe
en el que se muestran todas las computadoras en las que se encuentra cada paquete de software. Use Visible Analyst o
Microsoft Visio para ver el diagrama de flujo de dato 9.7. Use español estructurado para describir la siguiente lógica:
Para cada REGISTRO DE SOFTWARE (SOFTWARE RECORD), realizar una iteración mientras haya un número de
inventario de hardware que coincida.
Dentro del ciclo, realizar las siguientes tareas:
Leer el ARCHIVO MAESTRO DE COMPUTADORAS (COMPUTER MASTER).
Si se encuentra un registro, aplicar formato a la información del REGISTRO DE COMPUTADORA QUE COINCIDA
(MATCHING COMPUTER RECORD).
Si no se encuentra un registro, aplicar formato a una línea de error SIN COINCIDENCIAS (NO MATCHING).
Además, si el REGISTRO DE COMPUTADORA (COMPUTER RECORD) que se encontró está inactivo, indicando
que se retiró del servicio, aplicar formato a una línea de error de COMPUTADORA QUE COINCIDE INACTIVA
(INACTIVE MATCHING COMPUTER).www.xlibros.com

280 PARTE III • EL PROCESO DE ANÁLISIS
E-7. Cree la tabla de decisión BUSCAR UBICACIÓN DE SOFTWARE (FIND SOFTWARE LOCATION), la cual representa
la lógica para un programa de consulta que muestra todas las ubicaciones para un TÍTULO DE SOFTWARE (SOFT-
WARE TITLE) y VERSIÓN (VERSION) dados. Se crearon y optimizaron las condiciones para producir cinco reglas,
las cuales se ilustran en la figura E9.2. Introduzca las acciones que hay que introducir y una X en la columna relacionada
con las condiciones. Si utiliza un procesador de palabras, imprima la tabla de decisión final. Las condiciones y acciones
se representan mediante la siguiente lógica:
Se localiza el archivo MAESTRO DE SOFTWARE (SOFTWARE MASTER) para el TÍTULO (TITLE) especifi-
cado. Si no se encuentra un registro que coincida, se muestra un mensaje de error. Como puede haber varias versiones,
se revisa el NÚMERO DE VERSIÓN (VERSION NUMBER) en el registro para ver si coincide con la versión introdu-
cida. Si no se encuentra la versión solicitada, se leen más registros mediante el uso del índice alterno. SI se leen todos los
registros y no se encuentra el número de versión, se muestra el mensaje de error VERSIÓN NO DISPONIBLE (VER-
SION NOT AVAILABLE).
Una vez que se localiza el software correcto, se obtiene un registro ARCHIVO MAESTRO DE COMPUTADORAS
(COMPUTER MASTER) coincidente. Si no se encuentra el ARCHIVO MAESTRO DE COMPUTADORAS, se mues-
tra el mensaje de error NO SE ENCONTRÓ LA MÁQUINA (MACHINE NOT FOUND). Para cada máquina que coin-
cida, se busca en la TABLA DE CAMPUS (CAMPUS TABLE) el código de la UBICACIÓN DEL CAMPUS (CAMPUS
LOCATION). Si no se encuentra el código, se muestra el mensaje CAMPUS CODE NOT FOUND (NO SE ENCONTRÓ
EL CÓDIGO DE CAMPUS).
Si no hay errores, se muestra la información solicitada.
E-8. Cree una tabla de decisiones para una actualización por lotes de la tabla de base de datos ARCHIVO MAESTRO DE
COMPUTADORAS (COMPUTER MASTER). La información se envía de un campus regional en formato de XML que
contiene tres tipos de actualizaciones: Agregar (Add), Eliminar (Delete) y Modificar (Change).
Hay que leer el registro del ARCHIVO MAESTRO DE COMPUTADORAS. Si la transacción es Agregar y no se
encuentra el archivo maestro, aplicar formato y escribir el nuevo registro del ARCHIVO MAESTRO DE COMPUTADO-
RAS. Imprimir una línea de transacción válida en un INFORME DE ACTUALIZACIÓN (UPDATE REPORT). Para una
transacción Modificar o Eliminar, imprimir una LÍNEA DE ERROR DE MODIFICACIÓN (CHANGE ERROR LINE)
o una LÍNEA DE ERROR DE ELIMINACIÓN (DELETE ERROR LINE) si no se encuentra el registro en el ARCHIVO
MAESTRO DE COMPUTADORAS.
Si se encuentra el registro, revisar el código activo. Si el registro está inactivo y la transacción es Agregar, aplicar
formato y volver a escribir el nuevo registro del ARCHIVO MAESTRO DE COMPUTADORA. Imprimir una línea de
transacción válida en un INFORME DE ACTUALIZACIÓN. Para una transacción Modificar o Eliminar, imprimir una
LÍNEA DE ERROR DE MODIFICACIÓN o una LÍNEA DE ERROR DE ELIMINACIÓN.
Si el registro del ARCHIVO MAESTRO DE COMPUTADORA está activo y la transacción es Agregar, imprimir
una LÍNEA DE ERROR DE AGREGAR. Para una transacción Modificar, aplicar formato a los cambios y volver a es-
cribir el registro del ARCHIVO MAESTRO DE COMPUTADORA. Imprimir la LÍNEA DE TRANSACCIÓN VÁLIDA
(VALID TRANSACTION LINE). Para una transacción Eliminar, cambiar el CÓDIGO ACTIVO (ACTIVE CODE) a
inactivo y volver a escribir el registro del ARCHIVO MAESTRO DE COMPUTADORAS. Imprimir la LÍNEA DE
TRANSACCIÓN VÁLIDA (VALID TRANSACTION LINE).
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
Condiciones y acciones 1 2 3 4 5
Se encontró un registro de software que coincide
Se encontró la versión de software
Se encontró un registro de computadora que coincide
Se encontró código de campus en la tabla
Y Y Y Y N
Y Y Y N
Y Y N
Y N
Mostrar el mensaje de error ‘No hay registro de software que
coincida’
Mostrar el mensaje de error ‘Versión no disponible’
Mostrar el mensaje de error ‘No se encontró el código de campus’
Mostrar información sobre la ubicación
X
X
X
X
FIGURA E9.2
Tabla de decisión BUSCAR
UBICACIÓN DE SOFTWARE.www.xlibros.com

281
C A P Í T U L O 1 0
Análisis y diseño de sistemas
orientados a objetos
mediante el uso de UML1
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender qué es el análisis y diseño de sistemas orientados a objetos, y apreciar su utilidad.
2. Comprender los conceptos del lenguaje unificado de modelado (UML), la metodología
estándar para modelar un sistema en el mundo orientado a objetos.
3. Aplicar los pasos utilizados en el UML para descomponer el sistema en un modelo de
casos de uso y después en un modelo de clases.
4. Hacer diagramas de los sistemas con el conjunto de herramientas de UML, para poder
describirlos y diseñarlos en forma apropiada.
5. Documentar y comunicar el sistema orientado a objetos recién modelado para los
usuarios y demás analistas.
El análisis y diseño orientados a objetos pueden ofrecer una metodología
que facilita los métodos lógicos, rápidos y detallados para crear sistemas que
respondan a un panorama de negocios en evolución. Las técnicas orientadas
a objetos funcionan bien en situaciones en las que los sistemas de informa-
ción complicados pasan a través de un proceso continuo de mantenimiento,
adaptación y rediseño.
En este capítulo presentaremos el lenguaje unificado de modelado (UML), el estándar en la in-
dustria para modelar sistemas orientados a objetos. El conjunto de herramientas de UML incluye
diagramas que permiten visualizar la construcción de un sistema orientado a objetos. Cada iteración
aborda de manera cada vez más detallada el diseño del sistema, hasta que las cosas y las relaciones
en el sistema estén definidas con claridad y precisión en documentos de UML. El UML es una potente
herramienta que puede mejorar en forma considerable la calidad de nuestro análisis y diseño de
sistemas, y en consecuencia puede ayudarnos a crear sistemas de información de mayor calidad.
Cuando se introdujo la metodología orientada a objetos, sus defensores citaban la reutiliza-
ción de los objetos como su principal beneficio. Es lógico pensar que el reciclaje de las partes del
programa reduce los costos del desarrollo en los sistemas basados en computadoras, y esto ha
resultado un procedimiento muy efectivo en el desarrollo de GUI y bases de datos. Aunque la
reutilización es el principal objetivo, también es muy importante el mantenimiento de los sistemas
y, como la metodología orientada a objetos crea objetos que contienen tanto datos como código
de programa, si se modifica un objeto habrá un mínimo impacto en los demás objetos.
1 Por Julie E. Kendall, Kenneth E. Kendall y Allen Schmidt.www.xlibros.com

282 PARTE III • EL PROCESO DE ANÁLISIS
CONCEPTOS ORIENTADOS A OBJETOS
La programación orientada a objetos difiere de la programación tradicional por procedimientos en cuanto a que
examina los objetos que forman parte de un sistema. Cada objeto es una representación de alguna cosa o evento
real. En esta sección presentaremos las descripciones generales de los conceptos orientados a objetos clave: obje-
tos, clases y herencia. Más adelante en el capítulo presentaremos más detalles sobre otros conceptos de UML.
Objetos
Los objetos son personas, lugares o cosas relevantes para el sistema a analizar. Los sistemas orientados a objetos
describen las entidades como objetos. Algunos objetos comunes son clientes, artículos, pedidos, etcétera. Los
objetos también pueden ser pantallas de GUI o áreas de texto en la pantalla.
Clases
Por lo general, los objetos forman parte de un grupo de elementos similares, conocidos como clases. La intención
de colocar elementos en clases no es nuevo. Describir el mundo como algo compuesto de animales, vegetales y
minerales es un ejemplo de clasificación. La metodología científica incluye clases de animales (como mamífe-
ros) y después divide esas clases en subclases (como animales que ponen huevos, y mamíferos marsupiales).
La idea subyacente es tener un punto de referencia y describir un objeto específico en términos de sus simi-
litudes o diferencias en relación con los miembros de su propia clase. Al hacer esto es más eficiente para alguien
decir: “El oso koala es un marsupial (o animal con bolsa) con una cabeza grande y redonda, y con oídos pelu-
dos” que tratar de describir un oso koala a través de todas sus características como mamífero. Es más eficiente
describir las características, apariencia e incluso el comportamiento de esta manera. La palabra reutilizable, en el
mundo orientado a objetos, significa que se puede ser más eficiente gracias a que no hay necesidad de comenzar
desde el principio para describir cada objeto cada vez que se requiera en el desarrollo de software.
Los objetos se representan y agrupan mediante clases, las cuales son óptimas para la reutilización y la facili-
dad de mantenimiento. Una clase define el conjunto de atributos compartidos y comportamientos que se encuen-
tran en cada objeto de la clase. Por ejemplo, los registros para los estudiantes en la sección de un curso tienen
información similar almacenada para cada estudiante. Se dice que los estudiantes conforman una clase. Los valo-
res pueden ser distintos para cada estudiante, pero el tipo de información es el mismo. Los programadores deben
definir las diversas clases en el programa que escriben. Al ejecutarse el programa se pueden crear objetos a partir de
la clase establecida. El término instanciar se utiliza cuando se crea un objeto a partir de una clase. Por ejemplo,
un programa podría instanciar un estudiante llamado Peter Wellington como un objeto de la clase etiquetada
como estudiante.
Lo que distingue a la programación orientada a objetos (y por ende al análisis y diseño orientado a ob-
jetos) de la programación clásica es la técnica de colocar todos los atributos y métodos de un objeto dentro
de una estructura autocontenida, la clase en sí. Éste es un acontecimiento familiar en el mundo físico. Por
ejemplo, la mezcla de un pastel en caja es análoga a una clase, ya que tiene los ingredientes así como las
instrucciones sobre cómo mezclar y hornear el pastel. Un suéter de lana es similar a una clase, ya que tiene
una etiqueta cosida con instrucciones sobre su cuidado, que le advierten lavarlo a mano y dejarlo secar ex-
tendido.
Cada clase debe tener un nombre que la distinga de las demás. Por lo general, los nombres de las clases son
sustantivos o frases cortas y empiezan con mayúscula. En la figura 10.1 la clase se llama AutoRenta. En UML,
una clase se dibuja como un rectángulo. Este rectángulo contiene otras dos características importantes: una lista
de atributos y una serie de métodos. Estos elementos describen una clase, la unidad de análisis que forma una
gran parte de lo que llamamos análisis y diseño orientado a objetos.
Un atributo describe cierta propiedad que poseen todos los objetos de la clase. Cabe mencionar que la clase
AutoRenta posee los atributos de tamanio, color, marca y modelo. Todos los automóviles poseen estos atributos,
AutoRenta
tamanio
color
marca
modelo
rentar()
devolver()
reparar()
Nombre de la clase
Atributos
Métodos (operaciones)
FIGURA 10.1
Un ejemplo de una clase de UML,
la cual se describe como un
rectángulo que consiste en el
nombre de la clase, sus atributos y
métodos.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 283
pero cada automóvil tendrá distintos valores para sus atributos. Por ejemplo, un automóvil puede ser azul, blanco
o de algún otro color. Más adelante demostraremos que puede ser más específico sobre el rango de valores para
estas propiedades. Al especificar atributos, por lo general la primera letra va en minúscula.
Un método es una acción que se puede solicitar de cualquier objeto de la clase. Los métodos son los procesos
que una clase sabe cómo llevar a cabo. También se les conoce como operaciones. Para la clase AutoRenta, ren-
tar(), devolver() y reparar() son ejemplos de métodos. Al especificar métodos, por lo general la primera letra está
en minúscula.
Herencia
Otro concepto clave de los sistemas orientados a objetos es la herencia. Las clases pueden tener hijos; es decir, se
puede crear una clase a partir de otra. En UML, la clase original (o padre) se conoce como clase base; a la clase
hija se le denomina clase derivada. Podemos crear una clase derivada de tal forma que herede todos los atributos
y comportamientos de la clase base. Sin embargo, una clase derivada puede tener atributos y comportamientos
adicionales. Por ejemplo, podría haber una clase Vehículo para una empresa de renta de automóviles que con-
tenga atributos tales como tamaño, color y marca.
La herencia reduce la labor de programación al permitir que se utilicen los objetos comunes con facilidad. El
programador sólo necesita declarar que la clase Auto hereda de la clase Vehículo y después proporcionar todos
los detalles adicionales sobre los nuevos atributos o comportamientos que sean únicos para un automóvil.
Todos los atributos y comportamientos de la clase Vehículo pasan de manera automática e implícita a formar
parte de la clase Auto y no requieren de programación adicional. Esto permite al analista definir una vez pero
usar muchas veces; algo similar a los datos que están en la tercera forma normal, que se definen sólo una vez en
una tabla de la base de datos (como veremos en el capítulo 13).
Las clases derivadas que se muestran en la figura 10.2 son Auto o Camión. Aquí se antepone un signo ne-
gativo a los atributos y un signo positivo a los métodos. Más adelante en el capítulo hablaremos sobre esto con
más detalle; por ahora tenga en cuenta que los signos negativos significan que estos atributos son privados (no
se comparten con otras clases) y que los signos positivos significan que estos métodos son públicos (otras clases
pueden invocarlos).
Vehículo
–tamanio
–color
–marca
–modelo
–disponible
–tarifaPorDia
–tarifaPorSemana
–tarifaPorMilla
+rentar()
+devolver()
+reparar()
+agregarNuevo()
Auto
es un es un
–tamanio
–color
–marca
–modelo
–disponible
–tarifaPorDia
–tarifaPorSemana
–tarifaPorMilla
–estilo
+rentar()
+devolver()
+reparar()
+agregarNuevo()
Camion
–tamanio
–color
–marca
–modelo
–disponible
–tarifaPorDia
–tarifaPorSemana
–tarifaPorMilla
–longitud
–traccion4Ruedas
–cambioManual
+rentar()
+devolver()
+reparar()
+agregarNuevo()
FIGURA 10.2
Un diagrama de clases que
muestra la herencia. Auto y
Camion son ejemplos específicos
de vehículos y heredan las
características de la clase más
general, Vehículo.www.xlibros.com

284 PARTE III • EL PROCESO DE ANÁLISIS
La reutilización de código de programa ha formado parte del desarrollo de sistemas estructurados y los len-
guajes de programación (como COBOL) durante muchos años; además han existido subprogramas que encapsu-
lan datos. Sin embargo, la herencia es una herramienta que se encuentra sólo en los sistemas orientados a objetos.
TARJETAS CRC Y PENSAMIENTO EN OBJETOS
Ahora que hemos presentado los conceptos fundamentales del análisis y diseño orientados a objetos, necesitamos
examinar formas de crear clases y objetos a partir de los problemas de negocios y los sistemas a los que nos en-
frentamos. Una forma de empezar a poner en práctica la metodología orientada a objetos es empezar a pensar y
hablar de esta manera. Un método útil es desarrollar tarjetas CRC.
CRC representa a las clases, responsabilidades y colaboradores. El analista puede usar estos conceptos
cuando empieza a hablar sobre el sistema o a modelarlo a partir de una perspectiva orientada a objetos. Las
tarjetas CRC se utilizan para representar las responsabilidades de las clases y las interacciones entre ellas. Los
analistas crean las tarjetas con base en escenarios que describen los requerimientos del sistema. Estos escenarios
modelan el comportamiento del sistema que se está estudiando. Si se van a usar en un grupo, las tarjetas CRC
se pueden elaborar en forma manual en pequeñas tarjetas de cartulina por cuestión de flexibilidad, o se pueden
crear mediante el uso de una computadora.
Hemos agregado dos columnas a la plantilla de tarjeta CRC original: la columna Pensamiento en objetos
y la columna de propiedades. Los enunciados de Pensamiento en objetos están escritos en español común; el
nombre de la propiedad o atributo está escrito en su lugar apropiado. El propósito de estas columnas es aclarar el
pensamiento y ayudar a pasar a la creación de diagramas de UML.
Interacción durante una sesión CRC
Las tarjetas CRC se pueden crear de manera interactiva con unos cuantos analistas que puedan trabajar en con-
junto para identificar la clase en el dominio del problema presentado por la empresa. Una sugerencia es buscar to-
dos los sustantivos y verbos en un enunciado del problema que se haya creado para capturarlo. Por lo general, los
sustantivos indican las clases en el sistema; para encontrar las responsabilidades hay que identificar los verbos.
Haga una sesión de lluvia de ideas con su grupo de analistas para identificar todas las clases que pueda. Siga
el formato estándar para la lluvia de ideas, que consiste en no criticar la respuesta de ninguno de los participan-
tes en este punto, sino solicitar todas las respuestas posibles. Una vez identificadas todas las clases, los analistas
pueden empezar a compilarlas, eliminar las ilógicas y escribir cada una en su tarjeta. Asigne una clase a cada
persona en el grupo, que será su “propietaria” durante la sesión CRC.
A continuación, el grupo crea escenarios que en realidad son recorridos de las funciones del sistema, para
lo cual se toma la funcionalidad deseada del documento de requerimientos creado con anterioridad. Primero hay
que considerar los métodos de sistemas típicos, con excepciones tales como la recuperación de errores que se
lleva a cabo después de haber cubierto los métodos de rutina.
Mientras el grupo decide sobre la clase que será responsable de una función específica, el analista propieta-
rio de la misma durante la sesión elige esa tarjeta y declara: “Necesito cumplir con mi responsabilidad”. Cuando
O P O R T U N I D A D D E C O N S U L T O R Í A 1 0 . 1
Alrededor del mundo en 80 objetos
Como usted describió las ventajas de usar metodologías orienta-
das a objetos, Jules y Vern, dos ejecutivos de nivel superior en
World’s Trend desean que analice su empresa mediante el uso de
esta metodología. En la figura 7.15 encontrará un resumen de las
actividades de negocios de World’s Trend. Observe también la serie
de diagramas de flujo de datos en ese capítulo para que pueda con-
ceptualizar el problema y empiece a realizar la transición al Pensa-
miento en objetos.
Como usted es buen amigo de Jules y Vern, y no tiene incon-
veniente en obtener un poco de experiencia práctica en cuanto al
uso del pensamiento orientado a objetos, accede a aplicar lo que
sabe para después enviarles un informe.
Una vez que haya vuelto a leer las actividades de negocios para
World’s Trend, provea una revisión oportuna completando las si-
guientes tareas:
Use la técnica de tarjetas CRC para listar las clases, responsa-
bilidades y colaboradores.
Use la técnica de Pensamiento en objetos para listar lo que se
conoce y los atributos correspondientes para los objetos en las cla-
ses identificadas en la etapa anterior.
Haga un informe usando ambos pasos y vaya a las oficinas
generales de World’s Trend con su informe en la mano. Sin duda
Jules y Vern esperan un viaje fantástico en el nuevo mundo de los
métodos orientados a objetos.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 285
Nombre de la clase:
Superclases:
Subclases:
Responsabilidades Colaboradores Pensamiento en objetos Propiedad
Departamento
Agregar un nuevo departamento Curso Conozco mi nombre
Conozco mi silla del departamentoProveer información del departamento
Nombre del departamento
Nombre de la silla
Nombre de la clase:
Superclases:
Subclases:
Responsabilidades Colaboradores Pensamiento en objetos Propiedad
Curso
Agregar un nuevo curso Departamento Conozco el número de mi curso
Conozco mi descripción
Conozco mi número de créditosAsignación
Examen
Libro de textoModificar información del curso
Mostrar información del curso
Número de curso
Descripción del curso
Créditos
Nombre de la clase:
Superclases:
Subclases:
Responsabilidades Colaboradores Pensamiento en objetos Propiedad
Libro de texto
Agregar un nuevo libro de texto Curso Conozco mi ISBN
Conozco mi autor
Conozco mi título
Conozco mi edición
Conozco mi editorial
Sé si soy obligatorio
Edición
Editorial
Obligatorio
Cambiar la información del libro de texto
Buscar información del libro de texto
Eliminar libros de texto obsoletos
ISBN
Autor
Título
Nombre de la clase:
Superclases:
Subclases:
Responsabilidades Colaboradores Pensamiento en objetos Propiedad
Asignación
Agregar una nueva asignación Conozco mi número de asignación
Conozco mi descripción
Sé cuántos puntos valgo
Cambiar una asignación
Ver una asignación
Sé cuando me deben entregar
Número de tarea
Descripción de tarea
Puntos
Fecha de entrega
Curso
FIGURA 10.3
Cuatro tarjetas CRC
para los
ofrecimientos de
cursos, las cuales
muestran cómo los
analistas llenan
los detalles para las
clases,
responsabilidades y
colaboradores, así
como para los
enunciados de
pensamiento en
objetos y los
nombres de las
propiedades.
alguien sostiene una tarjeta en el aire, se considera un objeto y puede hacer cosas. Después el grupo procede a re-
finar la responsabilidad en tareas cada vez más pequeñas, de ser posible. Si es apropiado, el objeto pude cumplir
con estas tareas o el grupo puede decidir que se cumplan mediante la interacción con otras cosas. Si no existen
otras clases apropiadas, tal vez el grupo tenga que crear una.
Las cuatro tarjetas CRC descritas en la figura 10.3 muestran cuatro clases de ofrecimientos de cursos. Ob-
serve que en una clase llamada Curso, el analista de sistemas es referido a cuatro colaboradores: el departa-www.xlibros.com

286 PARTE III • EL PROCESO DE ANÁLISIS
mento, el libro de texto, la asignación del curso y el examen del curso. Después, estos colaboradores se describen
como clases por sí solas en las otras tarjetas CRC.
Las responsabilidades que se enlistan evolucionarán en un momento dado en lo que se conoce como méto-
dos en UML. Los enunciados de Pensamiento en objetos parecen rudimentarios, pero son conversacionales, de
tal forma que alientan a los analistas durante una sesión CRC a describir tantos de estos enunciados como pue-
dan. Como vimos en el ejemplo, todo el diálogo durante una sesión CRC se lleva a cabo en primera persona, de
manera que hasta el libro de texto habla: “Conozco mi ISBN”, “Conozco mi autor”. Después, estos enunciados
se pueden utilizar para describir atributos en UML. Podemos llamar a estos atributos según los nombres de sus
variables, como edicion y editorial.
CONCEPTOS Y DIAGRAMAS DEL LENGUAJE
UNIFICADO DE MODELADO (UML)
Es muy conveniente investigar y comprender la metodología del UML debido a su amplia aceptación y uso.
UML provee un conjunto estandarizado de herramientas para documentar el análisis y diseño de un sistema de
software. El conjunto de herramientas de UML incluye diagramas que permiten a las personas visualizar la cons-
trucción de un sistema orientado a objetos, algo similar a la forma en que los planos de construcción permiten a
las personas visualizar la construcción de un edificio. Ya sea que usted trabaje de manera independiente o con un
extenso equipo de desarrollo de sistemas, la documentación que puede crear con UML provee un medio efectivo
de comunicación entre el equipo de desarrollo y el equipo de negocios en un proyecto.
El UML consiste en cosas, relaciones y diagramas, como se muestra en la figura 10.4. Los primeros com-
ponentes (o elementos primarios) de UML se llaman cosas. Tal vez usted prefiera otra denominación, como
Categoría de UML
Cosas
Elementos de UML
Cosas estructurales
Cosas de
comportamiento
Interacciones
Máquinas de estado
Cosas de agrupamiento Paquetes
Cosas de anotaciones Notas
Clases
Interfaces
Colaboraciones
Casos de uso
Clases activas
Componentes
Nodos
Relaciones Relaciones estructurales Dependencias
Agregaciones
Asociaciones
Generalizaciones
Diagramas Diagramas estructurales Diagramas de clases
Diagramas de componentes
Diagramas de despliegue
Relaciones de
comportamiento
Comunica
Incluye
Extiende
Generaliza
Diagramas de
comportamiento
Diagramas de casos de uso
Diagramas de secuencia
Diagramas de comunicación
Diagramas de estados
Diagramas de actividad
Detalles específicos de UML
FIGURA 10.4
Una vista general de UML y sus
componentes: cosas, relaciones y
diagramas.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 287
objeto, pero en UML se les llama cosas. Las cosas estructurales son las más comunes. Las cosas estructurales
son clases, interfaces, casos de uso y muchos otros elementos que proveen la forma de crear modelos. Las cosas
estructurales permiten al usuario describir las relaciones. Las cosas de comportamiento describen la forma en
que funcionan las cosas. Algunos ejemplos de cosas de comportamiento son las interacciones y las máquinas
de estado. Las cosas de grupo se utilizan para definir límites. El paquete es un ejemplo de cosa de grupo. Por
último tenemos las cosas de anotaciones, para poder agregar notas en los diagramas.
Las relaciones son el pegamento que mantiene las cosas unidas entre sí. Es conveniente pensar en la relaciones
de dos formas. Las relaciones estructurales se utilizan para unir las cosas en los diagramas estructurales. Las relacio-
nes estructurales incluyen dependencias, agregaciones, asociaciones y generalizaciones. Por ejemplo, las relaciones
estructurales muestran herencia. Las relaciones de comportamiento se utilizan en los diagramas de comportamiento.
Los cuatro tipos básicos de relaciones de comportamiento son comunica, incluye, extiende y generaliza.
Hay dos tipos principales de diagramas en UML: diagramas estructurales y diagramas de comportamiento.
Los diagramas estructurales se utilizan, por ejemplo, para describir las relaciones entre las clases. Éstos se divi-
den en diagramas de clases, diagramas de objetos, diagramas de componentes y diagramas de despliegue. Por
otro lado, los diagramas de comportamiento se pueden utilizar para describir la interacción entre las personas
(actores en UML) y lo que denominamos caso de uso, o la forma en que los actores utilizan el sistema. Los
diagramas de comportamiento se dividen en diagramas de casos de uso, diagramas de secuencia, diagramas de
comunicación, diagramas de estados y diagramas de actividad.
En el resto del capítulo nos enfocaremos primero en el modelado de casos de uso, la base de todas las
técnicas de UML. Después analizaremos la forma en que se utiliza un caso de uso para derivar las actividades,
secuencias y clases: los diagramas de UML que se utilizan con más frecuencia. Como hay libros completos
dedicados a la sintaxis y el uso del UML (el documento oficial de especificaciones de UML tiene más de 800
páginas), proveeremos sólo un breve resumen de los aspectos más valiosos y más utilizados del UML.
Los seis diagramas de UML que se utilizan con más frecuencia son:
1. Un diagrama de casos de uso, que describe la forma en que se utiliza el sistema.
2. Un escenario de caso de uso (aunque técnicamente no es un diagrama). Este escenario es una articulación
verbal de excepciones para el comportamiento principal descrito por el caso de uso principal.
3. Un diagrama de actividad, que ilustra el flujo de actividades en general. Cada caso de uso puede crear un
diagrama de actividad.
4. Los diagramas de secuencia, que muestran la secuencia de las actividades y las relaciones entre las clases.
Cada caso de uso puede crear uno o más diagramas de secuencia. El diagrama de comunicación es la
alternativa a un diagrama de secuencia, el cual contiene la misma información pero enfatiza la comunicación
en vez de la sincronización.
5. Los diagramas de clases, que muestran las clases y sus relaciones. Los diagramas de secuencia se utilizan
(junto con las tarjetas CRC) para determinar las clases. El diagrama de generalización/especialización (gen/
spec) es un derivado del diagrama de clases.
6. Los diagramas de estados, que muestran las transiciones de estado. Cada clase puede crear un diagrama de
estados, el cual es útil para determinar los métodos de la clase.
En la figura 10.5 se ilustra la forma en que se relacionan estos diagramas entre sí. En las siguientes seccio-
nes hablaremos sobre cada uno de estos diagramas.
MODELADO DE CASOS DE USO
UML se basa fundamentalmente en una técnica de análisis orientado a objetos conocida como modelado de ca-
sos de uso, la cual se presentó en el capítulo 2. Un modelo de casos de uso muestra una vista del sistema desde
la perspectiva del usuario, por lo cual describe qué hace el sistema sin describir cómo lo hace. Podemos utilizar
UML para analizar el modelo de casos de uso y derivar los objetos del sistema junto con sus interacciones entre
sí y con los usuarios del sistema. Al utilizar técnicas de UML podemos analizar con más detalle los objetos y sus
interacciones para derivar su comportamiento, atributos y relaciones.
Un caso de uso provee a los desarrolladores un panorama sobre lo que desean los usuarios. Está libre de de-
talles técnicos o de implementación. Podemos pensar en un caso de uso como una secuencia de transacciones en
un sistema. El modelo de casos de uso se basa en las interacciones y relaciones de los casos de uso individuales.
Un caso de uso siempre describe tres cosas: un actor que inicia un evento, el evento que desencadena un
caso de uso y el caso de uso que realiza las acciones desencadenadas por el evento. En un caso de uso, un actor
que utiliza el sistema inicia un evento que a su vez genera una serie relacionada de interacciones en el sistema.
Los casos de uso se utilizan para documentar una transacción o evento individual. Se introduce un evento en el
sistema, el cual ocurre en un tiempo y lugar específicos para provocar que el sistema haga algo. Para obtener más
información sobre los símbolos de los casos de uso y cómo dibujar diagramas de casos de uso, vea el capítulo 2.www.xlibros.com

288 PARTE III • EL PROCESO DE ANÁLISIS
Cada caso de uso
puede crear un
diagrama de
actividad.
Cada escenario de
caso de uso puede
crear un diagrama
de secuencia.
Diagrama de clases
Diagrama de estados
Diagrama de secuencia
Diagrama de casos de uso
Diagrama de comunicación
1 1..
11
Diagrama de actividad
Los diagramas de
secuencia y
comunicación son
intercambiables.
Cada clase puede
tener un diagrama
de estados para
ayudar a determinar
las operaciones.
Los escenarios del
caso de uso se
pueden generar a
partir del diagrama
de caso de uso.
Los casos de uso
y los diagramas de
secuencia ayudan
a determinar
las clases.
Escenario de caso de uso
Identificadores
Pasos
Condiciones
FIGURA 10.5
Una vista general de los diagramas de UML que muestra cómo cada
diagrama conduce al desarrollo de otros diagramas de UML.
La figura 10.6 es el ejemplo de un caso de uso de la inscripción de estudiantes en una universidad. Cabe
mencionar que se representan sólo las funciones más importantes. El caso de uso Agregar estudiante no indica
cómo agregar estudiantes, el método de implementación. Los estudiantes se pueden agregar en persona, a través
de Web, mediante el uso de un teléfono de tonos o a través de una combinación de todos estos métodos. El caso de
uso Agregar estudiante incluye el caso de uso Verificar identidad para verificar la identidad del estudiante. El
caso de uso Comprar libro de texto extiende el caso de uso Inscribirse en clase y puede formar parte de un
sistema para inscribir a los estudiantes en un curso en línea.
Tal vez parezca que el caso de uso Cambiar información de estudiante fuera una característica menor del sis-
tema y no debiera incluirse en el diagrama de casos de uso, pero como esta información cambia con frecuencia, la ad-www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 289
ministración tiene mucho interés en permitir a los estudiantes cambiar su propia información personal. El hecho de que
los administradores consideren esto importante no sólo justifica, sino también exige, que se elabore el caso de uso.
No se debe permitir a los estudiantes cambiar el promedio de su calificación, las cuotas pendientes u otra
información relacionada. Este caso de uso también incluye el caso de uso Verificar identidad, que en esta situa-
ción significa que el estudiante tiene que introducir un ID de usuario y una contraseña para poder acceder al sis-
tema. Ver información de estudiante permite a los estudiantes ver su información personal, así como los cursos
y las calificaciones.
En la figura 10.7 se muestra el ejemplo de un escenario de caso de uso. Algunas de las áreas incluidas son
opcionales ya que tal vez no todas las organizaciones las utilicen. Las tres áreas principales son:
1. Un área de encabezado que contiene los identificadores e iniciadores de casos.
2. Los pasos realizados.
3. Un área al pie que contiene las precondiciones, suposiciones, preguntas y demás información.
En la primera área el caso de uso se identifica por su nombre, Cambiar información de estudiante; el actor
se identifica como Estudiante y se describen el Caso de uso y Evento desencadenador. La segunda área contiene
una serie de pasos que se realizan siempre y cuando no haya errores. Por último, en la tercera área se identifican
todas las pre- y post-condiciones, además de las suposiciones. Algunas de éstas son obvias, como la pre-condi-
ción de que el estudiante esté en la página Web correcta y la suposición de que el estudiante tenga un ID y con-
traseña válidos. Otras no son tan obvias, como la cuestión pendiente relacionada con las veces que se permite a
un estudiante iniciar sesión en el sistema.
<< incluye >>
<< incluye >>
<< incluye >>
<< incluye >>
<< extiende >>
RegistroEstudiante
Cambiar
información
de estudiante
Verificar
identidad
Oficina financiera
Tienda de libros
DepartamentoEstudiante
Transferir
créditos
Ver información
de estudiante
Comprar libro
de texto
Inscribirse
en clase
Agregar
estudiante
FIGURA 10.6
Ejemplo de casos de uso sobre la
inscripción de estudiantes.www.xlibros.com

290 PARTE III • EL PROCESO DE ANÁLISIS
Los diagramas de casos de uso proveen la base para crear otros tipos de diagramas, como los diagramas de
clases y los diagramas de actividad. Los escenarios de casos de uso son útiles para dibujar diagramas de secuen-
cia. Tanto los diagramas de casos de uso como los escenarios de casos de uso son potentes herramientas para
ayudarnos a comprender la forma en que un sistema funciona en general.
DIAGRAMAS DE ACTIVIDAD
Los diagramas de actividad muestran la secuencia de actividades en un proceso, incluyendo las actividades se-
cuenciales y paralelas, además de las decisiones que se toman. Por lo general se crea un diagrama de actividad
para un caso de uso y puede mostrar los distintos escenarios posibles.
En la figura 10.8 se muestran los símbolos en los diagramas de actividad. Un rectángulo con esquinas redon-
das representa una actividad, ya sea manual —como firmar un documento— o automatizada —como un método
o programa—.
Nombre del caso de uso: Cambiar información de estudiante ID única: Estudiante UC 005
Área:
Actor(es):
Descripción:
Evento desencadenador:
Pre-condiciones:
Post-condiciones:
Suposiciones:
Pasos realizados (ruta principal)
Sistema de estudiantes
El estudiante se encuentra en la página Web Cambiar información de estudiante.
El estudiante tiene un navegador y un ID de usuario y contraseña válidos.
El estudiante cambió con éxito su información personal.
Requerimientos cumplidos: Permitir que los estudiantes puedan cambiar su información personal mediante el uso de un sitio Web seguro.
Cuestiones pendientes: ¿Hay que controlar el número de veces que se permite a un estudiante iniciar sesión?
Prioridad: Media
Riesgo: Medio
El estudiante usa el sitio Web Cambiar información de estudiante, introduce el ID y contraseña de estudiante
y hace clic en el botón Enviar.
1. El estudiante inicia sesión en el servidor Web seguro.
2. Se lee el registro del estudiante y se verifica la contraseña.
3. La información personal actual del estudiante se muestra en la página
Web Cambiar datos de estudiante.
4. El estudiante introduce los cambios en el formulario Web Cambiar
datos de estudiante y hace clic en el botón Enviar.
5. Los cambios se validan en el servidor Web.
6. Se escribe el registro en el Diario de cambios de estudiantes.
7. Se actualiza el registro del estudiante en el Archivo maestro de estudiantes.
8. Se envía la página Web de confirmación al estudiante.
ID de estudiante, contraseña
Registro de estudiante, ID de estudiante, contraseña
Registro de estudiante
Formulario Web Cambiar datos de estudiante
Formulario Web Cambiar datos de estudiante
Formulario Web Cambiar datos de estudiante
Formulario Web Cambiar datos de estudiante, Registro de estudiante
Formulario Web Cambiar datos de estudiante
Tipo de desencadenador:
Estudiante
Permitir al estudiante cambiar su propia información tal como el nombre, la dirección de su casa, el número
telefónico de su casa, la dirección del campus, el número telefónico del campus, el número telefónico celular
y demás información mediante el uso de un sitio Web.
Información para los pasos
Externo Temporal
FIGURA 10.7
Un escenario de caso de uso se divide en tres secciones:
identificación e iniciación, pasos realizados y las condiciones,
suposiciones y preguntas.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 291
Una flecha representa a un evento. Los eventos representan cosas que ocurren en cierto momento y lugar.
Un diamante representa una decisión (también conocida como ramificación) o una fusión. En las decisiones
hay una flecha que entra al diamante y varias que salen de él. Se puede incluir una condición de guardia, que mues-
tra los valores de la condición. Las fusiones muestran varios eventos que se combinan para formar un evento.
Un rectángulo largo y plano representa una barra de sincronización. Estas barras se utilizan para mostrar las
actividades paralelas, donde puede haber un evento que entre a la barra de sincronización y varios eventos que
salgan de ella, a lo cual se le denomina bifurcación. Una sincronización en la que varios eventos se fusionan en
uno solo se denomina unión.
Hay dos símbolos que muestran el inicio y fin del diagrama. El estado inicial se muestra como un círculo
relleno. El estado final se muestra como un círculo negro rodeado por un círculo blanco.
Los rectángulos que rodean otros círculos se denominan carriles (swimlanes). Estos carriles indican particio-
namiento y se utilizan para mostrar qué actividades se realizan en cada plataforma, como un navegador, servidor
o computadora mainframe; también muestran las actividades que realizan distintos grupos de usuarios. Los carri-
les son zonas que pueden describir tanto la lógica como la responsabilidad de una clase.
En la figura 10.9 podemos ver un ejemplo de carriles. En esta figura se ilustra un diagrama de actividad
para el caso de uso Cambiar información de estudiante. Empieza con el estudiante al iniciar sesión en el sis-
tema mediante el proceso de llenar un formulario Web y hacer clic en el botón Enviar. El formulario se trans-
mite al servidor Web, el cual pasa a su vez los datos a la computadora mainframe. La mainframe accede a la
base de datos de ESTUDIANTES y pasa el mensaje “No se encontró” o los datos del estudiante seleccionado
al servidor Web.
El diamante debajo del estado Obtener registro de estudiante indica esta decisión. Si no se encontró el
registro del estudiante, el servidor Web muestra un mensaje de error en la página Web. Si se encontró el registro
del estudiante, el servidor Web da formato a una nueva página Web que contiene los datos del estudiante en un
formulario Web. El estudiante puede cancelar el cambio a través de los estados Iniciar sesión en sistema o In-
troducir cambios, y la actividad se detiene.
Si el estudiante introduce los cambios en el formulario y hace clic en el botón Enviar, los datos del cambio
se transmiten al servidor y se empieza a ejecutar un programa que valida los cambios. Si hay errores se envía un
mensaje de error a la página Web; si los datos son válidos se actualiza el registro de estudiantes y se escribe un Re-
gistro en el Diario de cambios de estudiantes. Después de una actualización válida, se envía una página Web de
confirmación al navegador y termina la actividad.
[condición] [sino]
Fusión
Ramificación
Unión
Bifurcación
Inicio
Actividad
Fin
ActividadActividadActividad
Podemos agregar
carriles a este
diagrama para
asignar
responsabilidades.
Las bifurcaciones
permiten realizar
actividades en
paralelo.
Las ramificaciones
permiten actividades
alternativas según
las distintas
condiciones.
FIGURA 10.8
Se utilizan símbolos
especializados para dibujar un
diagrama de actividad.www.xlibros.com

292 PARTE III • EL PROCESO DE ANÁLISIS
Creación de diagramas de actividad
Para crear diagramas de actividad hay que preguntarse qué ocurre primero y qué ocurre después. Debemos deter-
minar si las actividades se realizarán en secuencia o en paralelo. Si se crearon diagramas de flujo de datos físicos
(como vimos en el capítulo 7), hay que examinarlos para determinar la secuencia de las actividades. Busque los
lugares en donde se toman decisiones y pregunte qué ocurre en cada uno de los resultados de esas decisiones.
También podemos crear diagramas de actividad al examinar todos los escenarios de un caso de uso.
Cada ruta a través de las diversas decisiones incluidas en el caso de uso es un escenario distinto. En la ruta
principal estarían Iniciar sesión en sistema, Recibir formulario Web, Obtener registro de estudiante, Mos-
trar datos actuales de estudiante, Introducir cambios, Validar cambios, Actualizar registro de estudiante,
Crear registro en Diario de cambios de estudiantes y Mostrar confirmación.
Éste no es el único escenario que surge de este caso de uso. Puede haber otros. Una posibilidad podría ser Iniciar
sesión en sistema, Recibir formulario Web, Obtener registro de estudiante y Mostrar mensaje de error. Otro
escenario podría ser Iniciar sesión en sistema, Recibir formulario Web, Obtener registro de estudiante, Mos-
trar datos actuales de estudiante, Introducir cambios, Validar cambios y Mostrar mensaje de error.
Crear registro en
Diario de cambios
de estudiantes
Actualizar registro
de estudiante
Datos
válidos
Datos
válidos
ID de usuario y contraseña
No se encontró
Se colocaron datos de intercambio en
cola de mensajes
Estado del
registro
Actualización válida
Cancelar
Cancelar
Se actualizó
registro
Se escribió
registro
Iniciar sesión
en sistema
Página Web cliente Servidor Web Mainframe
Recibir formulario
Web
Mostrar mensaje
de error
Mostrar datos
actuales de estudiante
Validar cambios
Se recibieron datos válidos
Introducir cambios
Mostrar mensaje
de error
Mostrar
confirmación
Obtener registro
de estudiante
Se transmitió
formulario
Enviar mensaje de error
Se envió formulario Web
Se recibió
formulario Web
Enviar mensajes de error
Se envió confirmación
Se recibieron
datos inválidos
Estado de validación
FIGURA 10.9
Este diagrama de
actividad muestra tres
carriles: Página Web
cliente, Servidor
Web y Mainframe.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 293
Los carriles son útiles para mostrar cómo se debe transmitir o convertir datos, tales como los que van del
sitio Web al servidor, o del servidor a la mainframe. Por ejemplo, el diagrama de actividad de Cambiar registro
de estudiante tiene tres carriles.
El carril de la izquierda muestra las actividades que ocurren en el navegador cliente. Hay que crear páginas
Web para estas actividades. El carril de en medio muestra las actividades que ocurren en el servidor. Los eventos
como Se transmitió formulario representan los datos que se transmiten del navegador al servidor; debe haber
programas en el servidor para recibir y procesar los datos cliente.
El carril de la derecha representa la computadora mainframe. En empresas grandes es común para muchas
aplicaciones Web trabajar con una computadora mainframe. Gran parte de los datos en las grandes organizacio-
nes residen en bases de datos de equipos mainframe y hay una gran cantidad de programas para mainframe en
existencia.
Cuando un evento cruza el carril del servidor a la computadora mainframe, debe haber un mecanismo para
transmitir los datos del evento entre las dos plataformas. Los servidores usan un formato distinto para represen-
tar datos (ASCII) al que usan las computadoras mainframe (uno llamado EBCDIC). Debe haber middleware
presente para hacerse cargo de la conversión. A menudo, las computadoras IBM utilizan una cola de mensajes
(mqueue). La cola de mensajes recibe datos de los programas del servidor, los coloca en un área de retención y
llama a un programa de la mainframe, que por lo general está escrito en un lenguaje conocido como CICS. Este
programa recupera o actualiza los datos y envía los resultados de vuelta a la cola de mensajes.
En el diagrama de actividad de ejemplo antes mostrado, la decisión debajo del estado Obtener registro de
estudiante se toma en la computadora mainframe. Esto significa que la cola de mensajes recibe un mensaje “No
se encontró” o recibe el registro de la base de datos para el estudiante. Si la mainframe simplemente colocara Se
recibió estado de registro en la cola de mensajes y la decisión se evaluara en el servidor, éste tendría que llamar
a la mainframe de nuevo para obtener los datos válidos. Esto provocaría que la respuesta llegara más tarde a la
persona que espera en el navegador.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 0 . 2
Reciclando el entorno de programación
“Creo que estoy escribiendo el mismo código una y otra vez”,
dice Benito Pérez, un programador que trabaja en el nuevo diseño
de un almacén automatizado. “Últimamente he escrito tantos pro-
gramas relacionados con cosas de robots que se controlan a sí
mismas: carritos automatizados para la sala de correo, robots de
vigilancia de edificios, limpiadores de albercas automáticos, poda-
dores de césped automáticos, trenes de monorriel y ahora carritos
de almacén. Todas son variaciones del mismo tema”.
Lisa Bernoulli, gerente del proyecto, ha escuchado este tipo de
quejas durante años. Ella le contesta: “Oh, vamos Ben. Estas cosas en
realidad no están tan relacionadas. ¿Cómo puedes comparar un robot
de la sala de correo, un almacén automatizado y un tren de monorriel?
Apuesto a que menos del 10 por ciento del código es el mismo”.
“Mira”, dice Benito. “Los tres involucran máquinas que tienen
que buscar un punto inicial, seguir una ruta tortuosa, hacer paradas
para cargar y descargar y, en un momento dado, llegar a un punto
final. Los tres tienen que tomar decisiones en las ramificaciones de
sus rutas. Los tres tienen que evitar chocar con cosas. Estoy cansado
de rediseñar código que es bastante familiar para mí”.
“Hmmm”, reflexiona Lisa mientras da un vistazo a los requeri-
mientos básicos del sistema del almacén y recuerda el sistema de
monocarril en el que Benito y ella trabajaron el año pasado. Los reque-
rimientos se referían a una pequeña empresa de fabricación de apara-
tos electrónicos en lotes pequeños que deseaba automatizar su sistema
de almacén y movimiento de productos. El almacén contiene piezas
entrantes, trabajo en progreso y productos terminados. El almacén
automatizado utiliza un carrito robot de plataforma, similar a un ca-
rrito de golf, con la excepción de que no tiene asientos. Los carritos de
robot de plataforma tienen una superficie de carga plana de 6 × 4 pies’,
aproximadamente a 3 pies por encima del nivel del suelo. Estos carri-
tos tienen un dispositivo de radio comunicaciones que provee un en-
lace de datos en tiempo real a la computadora central del almacén. Los
carritos de plataforma tienen dos sensores: un sensor de ruta que
detecta un tipo especial de pintura y un sensor de movimiento
que detecta el movimiento. Estos carritos siguen rutas pintadas en el
piso de la fábrica. Los códigos especiales de pintura marcan bifurca-
ciones y ramificaciones en las rutas, los puntos de inicio y final del
carrito, además de los puntos de ubicaciones en general.
Las instalaciones incluyen tres estaciones de puertos de carga
y 10 estaciones de trabajo. Cada estación tiene una terminal de vi-
deo o computadora conectada a la computadora central. Cuando se
requieren productos o cuando están listos para ser recolectados de
una estación, el trabajador en la estación informa a la computadora
central. Después, la computadora central despacha los carritos se-
gún sea apropiado. Cada estación tiene un punto de entrega y un
punto de recolección. Los carritos de plataforma se desplazan por
la fábrica recogiendo el trabajo en los puntos de recolección y dejan
el trabajo en los puntos de entrega. El programa que opere los carri-
tos deberá interactuar mucho con el programa existente para pro-
gramar tareas que ayuda a establecer los horarios para las tareas de
las estaciones de trabajo.
¿Cómo debería Lisa proceder en cuanto a reutilizar el trabajo
que hizo Benito Pérez en el monocarril para adaptarlo a su tarea
actual de crear un objeto carrito? Explique en dos párrafos.www.xlibros.com

294 PARTE III • EL PROCESO DE ANÁLISIS
Los carriles también ayudan a dividir las tareas en un equipo. Se requieren diseñadores Web para las páginas
Web que se muestran en el navegador cliente. Otros miembros tendrían que trabajar con lenguajes de programa-
ción tales como Java, PHP, Ruby on Rails, PERL o .NET en el servidor. Los programadores de CICS de la main-
frame escribirían programas que funcionaran con la cola de mensajes. El analista debe asegurar que los datos que
necesitan los diversos miembros del equipo estén disponibles y definidos en forma correcta. Algunas veces los
datos en la cola de mensajes están en forma de un documento de XML. Si hay una organización externa involu-
crada, los datos también podrían ser un documento de XML.
El diagrama de actividad provee un mapa de un caso de uso; además permite al analista experimentar al
mover partes del diseño a distintas plataformas y preguntar: “¿Qué pasaría si?” para una variedad de decisiones.
El uso de símbolos únicos y carriles hace de este diagrama algo que las personas desean usar para comunicarse
con los demás.
Se pueden usar diagramas de actividad para construir planes de prueba. Hay que evaluar cada evento para
ver si el diagrama de actividad pasa al siguiente estado. Hay que evaluar cada decisión para ver si se toma la ruta
correcta cuando ocurren las condiciones de decisión.
Los diagramas de actividad no se utilizan para todos los casos. Debe usar diagramas de actividad cuando:
1. Le ayude a comprender las actividades de un caso de uso.
2. El flujo de control sea complejo.
3. Exista la necesidad de modelar el flujo de trabajo.
4. Haya que mostrar todos los escenarios.
El analista no necesita un diagrama de actividad cuando el caso de uso es simple, o cuando hay que modelar el
cambio de estado.
También se pueden usar los diagramas de actividad para modelar un método de nivel más bajo, en el que se
muestre la lógica detallada.
Entradas en el repositorio para un diagrama de actividad
Cada estado y evento se pueden definir con más detalle mediante el uso de una descripción de texto en el repo-
sitorio, el cual es una colección de descripciones de texto para el proyecto. Hay que describir los estados con
información sobre el estado, tal como el nombre de la página Web, los elementos de la página Web, y otros da-
tos. Hay que describir los eventos con la información requerida para comunicarse con el siguiente estado, como
los datos del formulario Web, los datos que se colocan en una cola de mensajes o mediante una descripción del
evento que ocasionó la transición, como el clic de un botón.
DIAGRAMAS DE SECUENCIA Y DE COMUNICACIÓN
Un diagrama de interacción puede ser un diagrama de secuencia o un diagrama de comunicación, ambos de los
cuales muestran esencialmente la misma información. Estos diagramas, junto con los diagramas de clases, se
utilizan para la realización de un caso de uso, lo cual es una forma de lograr o realizar un caso de uso.
Diagramas de secuencia
Los diagramas de secuencia pueden ilustrar una sucesión de interacciones entre clases o instancias de objetos a
través del tiempo. A menudo, los diagramas de secuencia se utilizan para ilustrar el procesamiento descrito en los
escenarios de casos de uso. En la práctica, los diagramas de secuencia se derivan del análisis de casos de uso y se
utilizan en el diseño de sistemas para derivar las interacciones, las relaciones y los métodos de los objetos en el
sistema. Los diagramas de secuencia se utilizan para mostrar el patrón general de las actividades o interacciones
en un caso de uso. Cada escenario de caso de uso puede crear un diagrama de secuencia, aunque éstos no siem-
pre se crean para escenarios de menor importancia.
En la figura 10.10 se muestran los símbolos utilizados en los diagramas de secuencia. Los actores y las cla-
ses o instancias de objetos se muestran en cuadros en la parte superior del diagrama. El objeto de más a la iz-
quierda es el objeto inicial y puede ser una persona (para la cual se utiliza un símbolo de actor de caso de uso),
ventana, cuadro de diálogo u otra interfaz de usuario. Algunas de las interacciones son sólo físicas, como la firma
de un contrato. Los rectángulos de la parte superior utilizan indicadores en el nombre para indicar si el rectán-
gulo representa un objeto, una clase, o una clase y un objeto.
nombreObjeto: Un nombre seguido de un signo de dos puntos representa a un objeto.
:clase Un signo de dos puntos seguido de un nombre representa a una clase.
nombreObjeto:clase Un nombre seguido de un signo de dos puntos y de otro nombre,
representa a un objeto en una clase.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 295
Una línea vertical representa la línea de vida de la clase u objeto, que corresponde al tiempo a partir del que se creó
hasta el momento en que se destruye. Una X en la parte inferior de la línea de vida representa el momento en que
se destruye el objeto. Una barra lateral o un rectángulo vertical en la línea de vida muestran el foco de control
cuando el objeto está ocupado haciendo cosas.
Las flechas horizontales muestran mensajes o señales que se envían entre las clases. Los mensajes perte-
necen a la clase receptora. Hay algunas variaciones en las flechas de los mensajes. Las puntas de flecha sólidas
representan llamadas sincrónicas, que son las más comunes. Éstas se utilizan cuando la clase emisora espera una
respuesta de la clase receptora y el control se devuelve a la clase emisora cuando la clase receptora que recibe el
mensaje termina de ejecutarse. Las medias puntas de flecha (o abiertas) representan llamadas asíncronas: aque-
llas que se envían sin esperar que la clase emisora las devuelva. Un ejemplo sería el uso de un menú para ejecutar
un programa. El retorno se muestra como una flecha, algunas veces con una línea punteada. Los mensajes se eti-
quetan mediante el uso de uno de los siguientes formatos:
El nombre del mensaje seguido de paréntesis vacíos: nombreMensaje().
El nombre del mensaje seguido de parámetros entre los paréntesis: nombreMensaje(parámetro1,
parámetro2 ...).
El nombre del mensaje seguido del tipo de parámetro, nombre del parámetro y cualquier valor
predeterminado para el parámetro entre paréntesis: nombreMensaje(tipoParámetro:nombreParámetro-
(valorPredeterminado). Los tipos de los parámetros indican el tipo de datos, como cadena, número o fecha.
El mensaje puede ser un estereotipo tal como <<Crear>> para indicar que se va a crear un nuevo objeto
como resultado del mensaje.
La sincronización en el diagrama de secuencia se muestra de arriba hacia abajo; la primera interacción se
dibuja en la parte superior del diagrama y la interacción que ocurre al último se dibuja en la parte inferior del
diagrama. Las flechas de interacción empiezan en la barra del actor u objeto que inicia la interacción y termi-
nan apuntando a la barra del actor u objeto que recibe la solicitud de interacción. El actor inicial u objeto se
muestra a la izquierda. Éste puede ser el actor que inicia la actividad o una clase que represente la interfaz de
usuario.
La figura 10.11 es un ejemplo simplificado de un diagrama de secuencia para un caso de uso que admite
a un estudiante en una universidad. A la izquierda está la clase interfazUsuarioNuevoEstudiante que se
utiliza para obtener la información del estudiante. El mensaje inicializar() se envía a la clase Estudiante, la
cual crea un nuevo registro de estudiante y devuelve el número de estudiante. Para simplificar el diagrama
omitimos los parámetros que se envían a la clase Estudiante, pero éstos deben incluir el nombre del estu-
diante, su dirección y otros. La siguiente actividad es enviar un mensaje seleccionarDormitorio a la clase
método(Parámetro)
retorno
señalAsíncrona()
::Clase Objecto::Clase
FIGURA 10.10
Símbolos especializados que se
utilizan para dibujar un diagrama
de secuencia.www.xlibros.com

296 PARTE III • EL PROCESO DE ANÁLISIS
Dormitorio. Este mensaje debe incluir la información de selección del dormitorio, como un dormitorio para
el cuidado de la salud u otros requerimientos del estudiante. La clase Dormitorio devuelve el nombre del
dormitorio y el número de habitación. La tercera actividad es enviar un mensaje seleccionarPrograma a
la clase Programa, incluyendo el nombre del programa y demás información sobre el curso de estudio. Se
devuelve el nombre del consejero del programa a la clase interfazUsuarioNuevoEstudiante. Se envía un
mensaje estudianteCompleto a la clase Estudiante con el nombre del dormitorio, del consejero y demás
información pertinente.
Los diagramas de secuencia se pueden utilizar para traducir el escenario de caso de uso en una herramienta
visual para el análisis de sistemas. El diagrama de secuencia inicial utilizado en el análisis de sistemas muestra
los actores y las clases en el sistema, así como las interacciones entre ellos para un proceso específico. Usted
puede utilizar esta versión del diagrama de secuencia para verificar los procesos con los expertos del área de ne-
gocios que le hayan ayudado a desarrollar los requerimientos del sistema. Un diagrama de secuencia hace énfasis
en el orden de los mensajes (secuencia) en el tiempo.
Durante la fase de diseño de sistemas, los diagramas de secuencia se refinan para derivar los métodos y las
interacciones entre las clases. Los mensajes de una clase se utilizan para identificar las relaciones de las clases.
Los actores en los primeros diagramas de secuencia se traducen en interfaces y las interacciones de las clases
se traducen en métodos de clase. Los métodos de clase que se utilizan para crear instancias de otras clases y
realizar otras funciones internas del sistema se revelan en el diseño del sistema mediante el uso de diagramas
de secuencia.
Diagramas de comunicación
Los diagramas de comunicación se introdujeron en el UML 2.0. Su nombre original en el UML 1.x era diagra-
mas de colaboración. Los diagramas de comunicación describen las interacciones entre dos o más cosas en el
sistema que desempeñan un comportamiento mayor a lo que cualquiera de las dos cosas pueden hacer por su
cuenta. Por ejemplo, un automóvil se puede descomponer en varios miles de piezas individuales. Las piezas se
conectan para formar los subsistemas principales del vehículo: el motor, la transmisión, el sistema de frenos,
etcétera. Las piezas individuales del automóvil se pueden considerar como clases, ya que tienen distintos atri-
butos y funciones. Las piezas individuales del motor forman una colaboración, ya que se “comunican” entre sí
para hacer que el motor funcione cuando el conductor pisa el acelerador.
Un diagrama de comunicación consta de tres partes: los objetos (también llamados participantes), los enla-
ces de comunicación y los mensajes que se pueden pasar a través de esos enlaces. Los diagramas de comunica-
::Estudiante
inicializar( )
seleccionarDormitorio( )
estudianteCompleto( )
regresar cuartoDormitorio
regresar numeroEstudiante
::dormitorio ::programa
::interfazUsuario
NuevoEstudiante
seleccionarPrograma( )
regresar consejeroPrograma
FIGURA 10.11
Un diagrama de secuencia para
admitir a un estudiante. Los
diagramas de secuencia hacen
énfasis en el orden de los mensajes
en el tiempo.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 297
ción muestran la misma información que un diagrama de secuencia, pero pueden ser más difíciles de leer. Para
poder mostrar el orden en el tiempo, debemos indicar un número de secuencia y describir el mensaje.
Un diagrama de comunicación hace énfasis en la organización de los objetos, mientras que un diagrama de
secuencia hace énfasis en el orden de los mensajes en el tiempo. Un diagrama de comunicación mostrará una
ruta para indicar cómo está un objeto enlazado con otro.
Cierto software de modelado de UML, como Rational Rose de IBM, convierte con el clic de un botón un
diagrama de secuencia en un diagrama de comunicación, o un diagrama de comunicación en un diagrama de
secuencia. En la figura 10.12 se muestra el diagrama de comunicación para admitir a un estudiante. Cada rectán-
gulo representa a un objeto o una clase. Las líneas conectoras muestran las clases que necesitan colaborar o tra-
bajar entre sí. Los mensajes que se envían de una clase a otra se muestran a lo largo de las líneas conectoras. Los
mensajes están numerados para mostrar la secuencia en el tiempo. También se pueden incluir valores de retorno
y se pueden enumerar para indicar cuándo se devuelven dentro de la secuencia de tiempo.
DIAGRAMAS DE CLASES
Las metodologías orientadas a objetos trabajan para descubrir las clases, atributos, métodos y relaciones entre
las clases. Como la programación ocurre a nivel de clase, definir clases es una de las tareas más importantes del
análisis orientado a objetos. Los diagramas de clases muestran las características estáticas del sistema y no repre-
sentan ningún procesamiento en especial. Un diagrama de clases también muestra la naturaleza de las relaciones
entre las clases.
En un diagrama de clases, las clases se representan mediante un rectángulo. En el formato más simple, el
rectángulo puede incluir sólo el nombre de la clase, pero también puede incluir atributos y métodos. Los atribu-
tos son lo que la clase conoce sobre las características de los objetos, y los métodos (también llamados operacio-
nes) son lo que la clase sabe acerca de cómo hacer las cosas. Los métodos son pequeñas secciones de código que
trabajan con los atributos.
La figura 10.13 muestra un diagrama de clases para los ofrecimientos de cursos. Cabe mencionar que el
nombre está centrado en la parte superior de la clase, por lo general en negrita. El área justo debajo del nombre
muestra los atributos y la porción inferior lista los métodos. El diagrama de clases muestra los requerimientos de
almacenamiento de datos, así como los requerimientos de procesamiento. Más adelante en el capítulo hablare-
mos sobre el significado de los símbolos de diamante que se muestran en esta figura.
Por lo general los atributos (o propiedades) se designan como privados, o que sólo están disponibles en el
objeto. En un diagrama de clases esto se representa con un signo negativo al inicio del nombre del atributo. Los
atributos también pueden ser protegidos, lo cual se indica con un símbolo (#). Estos atributos están ocultos para
todas las clases, excepto las subclases inmediatas. Bajo raras circunstancias un atributo se hace público, lo cual
significa que otros objetos fuera de su clase pueden verlo. Hacer los atributos privados implica que serán visibles
sólo para los objetos externos a través de los métodos de la clase, una técnica que se conoce como encapsula-
miento u ocultamiento de la información.
Un diagrama de clase puede mostrar sólo el nombre de la clase, el nombre de la clase y los atributos o el
nombre de la clase, los atributos y los métodos. Es útil mostrar sólo el nombre de la clase cuando el diagrama es
muy complejo e incluye muchas clases. Si el diagrama es más simple, se pueden incluir los atributos y los méto-
dos. Cuando se incluyen los atributos hay tres formas de mostrar la información de cada uno. La más simple es
incluir sólo el nombre del atributo, lo cual ocupa la menor cantidad de espacio.
1:inicializar( )
3:seleccionarPrograma( )
2:seleccionarDormitorio( )
4:estudianteCompleto( )
::estudiante ::programa
::dormitorio
::ninterfazUsuario
NuevoEstudiante
FIGURA 10.12
Un diagrama de comunicación para admitir a un
estudiante. Los diagramas de comunicación muestran
la misma información que se describe en un diagrama
de secuencia, pero hacen énfasis la organización de
los objetos en vez del orden en el tiempo.www.xlibros.com

298 PARTE III • EL PROCESO DE ANÁLISIS
Departamento
–nombreDepartamento
–sillaDepartamento
+agregarDepartamento()
+verDepartamento()
Curso
–numeroCurso
–descripcionCurso
–numeroCreditos
–numeroDepartamento
+agregarCurso()
+cambiarCurso()
+buscarCurso()
Librotexto
–ISBN
–autor
–titulo
–edicion
–editorial
–requerido
+agregarTexto()
+cambiarTexto()
+buscarTexto()
+quitarTexto()
Examen
–numeroExamen
–nombreExamen
–puntosExamen
–versionExamen
+agregarExamen()
+cambiarExamen()
+buscarExamen()
Asignacion
–numeroAsignacion
–descripcionAsignacion
–puntosAsignacion
–fechaEntregaAsignacion
+agregarAsignacion()
+cambiarAsignacion()
+verAsignacion()
tiene un
es
parte
de
es
parte
de
consiste
de
es para un
1 1..
consiste
de
FIGURA 10.13
Un diagrama de clases para los
ofrecimientos de cursos. Los
diamantes rellenos muestran
agregación y los diamantes
vacíos muestran una relación
entre un todo y sus partes.
Se puede incluir el tipo de datos (como cadena, doble, entero o fecha) en el diagrama de clases. Las des-
cripciones más completas incluyen un signo de igual (=) después del tipo de datos, seguido del valor inicial del
atributo. La figura 10.14 ilustra los atributos de las clases.
Si el atributo debe tomar un valor de un número finito de ellos, como un tipo de estudiante con valores de C
para tiempo completo, P para tiempo parcial y N para no matriculado, éstos se pueden incluir entre llaves separa-
dos por comas: tipoEstudiante: char{F,P,N}.
El ocultamiento de información significa que los métodos de los objetos deben estar disponibles para otras
clases, por lo que comúnmente los métodos son públicos, lo cual significa que se pueden invocar desde otras
clases. En un diagrama de clases, los mensajes públicos (al igual que los atributos públicos) se muestran con un
signo positivo (+) al inicio del nombre correspondiente. Los métodos también tienen paréntesis después de su
nombre, lo cual indica que se pueden pasar datos como parámetros junto con el mensaje. En el diagrama de cla-
ses se pueden incluir los parámetros del mensaje, así como el tipo de datos.
Hay dos tipos de métodos: estándar y personalizados. Los métodos estándar son las cosas básicas que todas
las clases de objetos saben cómo hacer, como crear una nueva instancia de un objeto. Los métodos personaliza-
dos están diseñados para una clase específica.
Sobrecarga de métodos
La sobrecarga de métodos se refiere a incluir el mismo método (u operación) varias veces en una clase. La firma
del método incluye su nombre y los parámetros que incluye. El mismo método se puede definir más de una vez
en una clase dada, siempre y cuando los parámetros que se envían como parte del mensaje sean distintos; es de-
cir, debe haber una firma de mensaje distinta. Puede haber un número distintos de parámetros, o éstos pueden ser
de un tipo distinto, como un número en un método y una cadena de texto en otro método. Podemos encontrar un
FIGURA 10.14
Una clase Estudiante extendida
que muestra el tipo de datos y, en
algunos casos, su valor inicial o
valor predeterminado.
Estudiante
numeroEstudiante: Integer
apellidoPaterno: String
primerNombre: String
creditosCompletados: Decimal=0.0
promedioCalif: Decimal=0.0
estudianteActual: Boolean=Y
fechaInscripcion: Fecha=
new()
cambiarEstudiante()
verEstudiante()www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 299
ejemplo de sobrecarga de métodos en el uso de un signo de suma en muchos lenguajes de programación. Si los
atributos en ambos lados del signo de suma son números, se suman los dos números. Si los atributos son cadenas
de caracteres, las cadenas se concatenan para formar una sola cadena extensa.
En un ejemplo de un depósito bancario, un recibo de depósito podría contener sólo el monto a depositar, en
cuyo caso el banco depositaría el monto completo, o podría contener el monto a depositar y la cantidad de efec-
tivo a devolver. Ambas situaciones utilizarían un método de verificación de depósito, pero los parámetros (una de
las situaciones también requeriría devolver el monto de efectivo) serían distintos.
Tipos de clases
Las clases se dividen en cuatro categorías: de entidad, de interfaz, abstracta y de control. A continuación expli-
caremos estas categorías.
CLASES DE ENTIDAD Las clases de entidad representan elementos del mundo real como personas o cosas,
por ejemplo. Las clases de entidad son las entidades representadas en un diagrama de entidad-relación. Las
herramientas CASE como Visible Analyst le permiten crear una clase de entidad de UML a partir de una entidad
en un diagrama E-R.
El analista necesita determinar qué atributos debe incluir en las clases. Cada objeto tiene muchos atributos,
pero la clase debe incluir sólo aquellos que la organización utilice. Por ejemplo, al crear una clase de entidad
para un estudiante en una universidad necesitamos conocer los atributos que identifican al estudiante, como la
dirección de su hogar y del campus al que pertenece, así como el promedio de sus calificaciones, los créditos
totales, etcétera. Si tuviera que llevar el registro del mismo estudiante para una tienda de ropa en línea, tendría
que conocer la información básica de identificación además de otros atributos descriptivos como las medidas o
preferencias de color.
CLASES DE LÍMITE O DE INTERFAZ Las clases de límite o de interfaz proveen los medios para que los usuarios
trabajen con el sistema. Hay dos amplias categorías de clases de interfaz: humana y de sistema.
Una interfaz humana puede ser una pantalla, una ventana, un formulario Web, un cuadro de diálogo, un
menú, un cuadro de lista u otro control de visualización. También puede ser un teléfono de tonos, código de ba-
rras o cualquier otra forma en que los usuarios puedan interactuar con el sistema. Hay que crear prototipos de las
interfaces humanas (como vimos en el capítulo 6) y a menudo se utiliza un guión gráfico para modelar la secuen-
cia de interacciones.
Las interfaces del sistema necesitan enviar o recibir datos de otros sistemas. Esto puede incluir a las bases
de datos en la organización. Si se envían datos a una organización externa, por lo general se hace en la forma de
archivos de XML u otras interfaces reconocidas con mensajes y protocolos claramente definidos. Las interfaces
externas son las menos estables, ya que a menudo hay muy poco o nada de control sobre un socio externo capaz
de alterar el formato del mensaje o de los datos.
El XML ayuda a proveer estandarización, ya que un socio externo puede agregar nuevos elementos al docu-
mento de XML, aunque una corporación que transforme los datos en un formato que se pueda utilizar para agre-
gar información a una base de datos interna puede ignorar los elementos adicionales sin ningún problema.
Los atributos de estas clases son los que se encuentran en la pantalla o informe. Los métodos son los que se
requieren para trabajar con la pantalla o para producir el informe.
CLASES ABSTRACTAS Las clases abstractas son clases que no se pueden instanciar en forma directa. Las clases
abstractas están enlazadas a clases concretas en una relación de generalización/especialización (gen/spec). Por lo
general el nombre de una clase abstracta se escribe en cursiva.
CLASES DE CONTROL Las clases de control o activas se utilizan para controlar el flujo de actividades; actúan
como un coordinador a la hora de implementar las clases. Para obtener clases que se puedan reutilizar, un
diagrama de clases puede incluir muchas clases de control pequeñas. A menudo las clases de control se derivan
durante el diseño del sistema.
Es común crear una clase de control sólo para poder reutilizar otra clase. Un ejemplo de ello sería el proceso
de inicio de sesión. Podría haber una clase de control que se encargue de la interfaz de usuario de inicio de sesión,
que contiene la lógica para verificar el ID y la contraseña del usuario. El problema que surge es que la clase de
control del inicio de sesión está diseñada para una pantalla de inicio de sesión específica. Al crear una clase
de control de inicio de sesión que maneje sólo la pantalla de inicio de sesión única, los datos se pueden pasar a
una clase de control de validación más general, la cual verifica los ID y contraseñas de usuario que recibe de mu-
chas otras clases de control que reciben mensajes de interfaces de usuario específicas. Esto incrementa la reutiliza-
ción y aísla los métodos de verificación de inicio de sesión de los métodos para manejar la interfaz de usuario.
Las reglas para crear diagramas de secuencia son que todas las clases de interfaz deben estar conectadas a una
clase de control. De manera similar, todas las clases de entidad deben estar conectadas a una clase de control. Las cla-
ses de interfaz, a diferencia de las otras dos, nunca se conectan de manera directa a las clases de entidad.www.xlibros.com

300 PARTE III • EL PROCESO DE ANÁLISIS
Definición de mensajes y métodos
Podemos definir cada mensaje mediante una notación similar a la que se describe para el diccionario de da-
tos (como vimos en el capítulo 8). La definición debe incluir una lista de los parámetros que se pasan con
el mensaje, así como los elementos contenidos en el mensaje de retorno. Los métodos pueden tener lógica
definida mediante español estructurado, una tabla de decisión o un árbol de decisión, como vimos en el ca-
pítulo 9.
El analista puede usar las técnicas de balanceo horizontal con cualquier método de clase. Todos los datos
que se devuelven de una clase de entidad se deben obtener de los atributos almacenados en la clase de entidad,
de los parámetros que se pasan en el mensaje que se envía a la clase o como resultado de un cálculo realizado
por el método de la clase. Hay que examinar la lógica y los parámetros del método para asegurar que la lógica
del método tenga toda la información requerida para completar su tarea. En el capítulo 7 se describe el balanceo
horizontal con más detalle.
CÓMO MEJORAR LOS DIAGRAMAS DE SECUENCIA
Una vez dibujado el diagrama de clases, tal vez sea conveniente regresar al diagrama de secuencia e incluir sím-
bolos especiales para cada uno de los distintos tipos de clases que introdujimos en la sección anterior. En particu-
lar, los diagramas de secuencia pueden ser abrumadores si un analista no tiene una metodología sistemática para
dibujarlos. Los siguientes pasos son un método útil para mejorar un diagrama de secuencia:
1. Incluya el actor del diagrama de caso de uso en el diagrama de secuencia mejorado. Éste será una figura de
palitos del diagrama de caso de uso. Puede haber un actor adicional del lado derecho del diagrama, como
una compañía de tarjetas de crédito o un banco.
2. Defina una o más clases de interfaz para cada actor. Cada actor debe tener su propia clase de interfaz.
3. Cree prototipos de páginas Web para todas las interfaces humanas.
4. Asegúrese de que cada caso de uso tenga una clase de control, aunque se pueden crear más durante el diseño
detallado. Busque esa clase de control e inclúyala en el diagrama de secuencia.
5. Examine el caso de uso para ver qué clases de entidad están presentes. Incluya éstas en el diagrama.
6. Tenga en cuenta que el diagrama de secuencia se puede modificar de nuevo al realizar el diseño detallado,
como cuando se crean páginas Web o clases de control adicionales (una para cada formulario Web enviado).
7. Para obtener un mayor grado de reutilización, considere mover los métodos de una clase de control a una
clase de entidad.
Un ejemplo de clase para Web
Las clases también se pueden representar mediante el uso de símbolos especiales para las clases de entidad, de
límite (o interfaz) y de control. A estos símbolos se les denomina estereotipos, una extensión para el UML; son
símbolos especiales que se pueden utilizar durante el análisis, pero a menudo se utilizan al momento de realizar
el diseño orientado a objetos. Estos símbolos permiten al analista la libertad de jugar con el diseño para optimi-
zar el grado de reutilización.
Los distintos tipos de clases se utilizan con frecuencia al trabajar en la fase de diseño de sistemas. La figura
10.15 es un ejemplo que muestra un diagrama de secuencia que representa a un estudiante que ve su información
personal y del curso. En el diagrama, :Interfaz de usuario ver estudiante es un ejemplo de una clase de inter-
faz; :Estudiante, :Seccion y :Curso son ejemplos de clases de entidad; :Controlador interfaz ver estudiante y
:Calcular promedio calificacion son clases de control.
El estudiante se muestra a la izquierda como un actor y proporciona un inicioSesionUsuario a la clase
:Interfaz de usuario ver estudiante. Éste es un formulario Web que obtiene el ID y la contraseña del usuario.
Cuando el estudiante hace clic en el botón Enviar, el formulario Web se pasa a un :Controlador interfaz ver
estudiante. Esta clase es responsable de la coordinación al enviar los mensajes y recibir la información devuelta
por las demás clases.
El :Controlador interfaz ver estudiante envía un mensaje obtenerEstudiante() a la clase :Estudiante, la
cual lee una tabla en la base de datos y procede a devolver los datosEstudiante.
La paginaWebEstudiante se devuelve a la :Interfaz de usuario ver estudiante, la cual muestra la in-
formación en el navegador Web. Al final de la página hay un botonSiguiente, en el cual el estudiante hace
clic para ver los cursos. Hacer clic en este botón envía un formulario Web al :Controlador interfaz ver es-
tudiante. Este formulario contiene el numeroEstudiante() que se envía junto con la paginaWebEstudiante
y se utiliza para enviar un mensaje a la clase :Seccion para que obtenga la calificación de la sección. Si no
se enviara el numeroEstudiante() en forma automática, el estudiante tendría que introducir su numeroEstu-www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 301
diante() de nuevo, lo cual implicaría un insatisfactorio tecleo redundante. Cabe mencionar que la clase :Estu-
diante no está involucrada y que el foco de control (la barra vertical conectada a la clase :Estudiante) termina
antes de que empiece el segundo conjunto de actividades (las flechas horizontales que apuntan a la derecha).
La clase :Controlador interfaz ver estudiante envía un mensaje obtenerSeccion() a la clase :Seccion, la
cual devuelve una calificacionSeccion. La clase :Seccion también envía un mensaje calcularGPA() a la clase
:Calcular promedio calificacion, la cual envía un mensaje de vuelta a la clase :Curso. La clase :Curso de-
vuelve los creditos que permiten a la clase :Calcular promedio calificacion determinar el GPA y devolverlo al
:Controlador interfaz ver estudiante.
:Interfaz de
usuario ver
estudiante
:Controlador
interfaz ver
estudiante
:Estudiante :Seccion :Curso
:Calcular
promedio
calificacion
Clase de
límite o
de interfaz
Clase de
entidad
Clase de
control
Estudiante
proveer
inicioSesionUsuario iniciarSesion() obtenerEstudiante()
regresar
datosEstudiante
regresar pagina-
WebEstudiante
regresar
paginaWebCurso
mostrar
paginaWebCurso
mostrar pagina-
WebEstudiante
hacer clic en
botonSiguiente
enviar
numeroEstudiante( ) obtenerSeccion( )
regresar
calificacionSeccion
calcularGPA( )
obtenerCurso( )
regresar creditos
obtenerCreditos( )
regresar datosCurso
regresar GPA
FIGURA 10.15
Un diagrama de secuencia para usar dos páginas Web: una para la
información del estudiante y la otra para la información del curso.www.xlibros.com

302 PARTE III • EL PROCESO DE ANÁLISIS
El :Controlador interfaz ver estudiante repite el envío de mensajes a la clase :Seccion hasta que se ha-
yan incluido todas las secciones para el estudiante. En este momento, :Controlador interfaz ver estudiante
envía la paginaWebCurso a la clase :Interfaz usuario ver estudiante, que muestra la información en el
navegador.
Al utilizar las clases de interfaz de usuario, de control y de entidad, el analista puede explorar el diseño y
experimentar con él. El diseño antes mencionado mostraría toda la información personal del estudiante en una
página y la información del curso en una segunda página. El analista puede modificar el diseño de manera que la
información personal del estudiante y la información del curso aparezcan en una página Web. Estos dos posibles
escenarios se revisarían con los usuarios para determinar la mejor opción.
Una de las dificultades para el analista es determinar cómo incluir el numeroEstudiante después de hacer
clic en el botón Siguiente, ya que la clase :Estudiante no está disponible en ese momento. Hay tres formas de
almacenar y retransmitir los datos desde una página Web:
1. Incluir la información en el URL que se muestra en el área de dirección o ubicación del navegador. En este
caso, la línea de la ubicación podría mostrar algo así: http://www.cpu.edu/estudiante/consultestud.
html?numeroEstudiante=12345
Todo lo que va después del signo de interrogación son datos que los métodos de clase pueden utilizar.
Este medio de almacenar los datos es fácil de implementar y se utiliza con frecuencia en los motores de
búsqueda.
Hay varias desventajas en cuanto a usar este método, por lo que el analista debe tener cuidado. La
primera preocupación es la privacidad; cualquiera puede leer la dirección Web. Si la aplicación involucra
información médica, números de tarjeta de crédito, etcétera, ésta no es una buena opción. La mayoría de los
navegadores también muestran los datos de direcciones Web anteriores en sesiones posteriores si el usuario
introduce los primeros caracteres, por lo que la información se puede ver comprometida, dando pie al robo
de identidad. Una segunda desventaja es que por lo general los datos se pierden una vez que el usuario cierra
el navegador.
2. Almacenar la información en una cookie: un pequeño archivo almacenado en la computadora cliente
(navegador). Las cookies constituyen la única forma de almacenar datos para que persistan más allá de
la sesión actual del navegador. Esto permite a la página Web mostrar un mensaje tal como “Bienvenido
de vuelta, Robin. Si no es usted Robin, haga clic aquí”. Por lo general las cookies almacenan números de
cuenta de claves primarias pero no números de tarjetas de crédito u otro tipo de información privada. Las
cookies están limitadas a 20 por dominio (como www.cpu.edu) y cada cookie debe ser de 4,000 caracteres
o menor.
El analista debe trabajar con otras unidades de negocios para determinar quién necesita usar cookies y
debe haber cierto control central sobre los nombres utilizados en las cookies. Si la organización necesita
tener más de 20 cookies, una solución común es crear distintos nombres de dominio utilizados por la
organización, como soporte.cpu.edu o capacitacion.cpu.edu.
3. Use campos ocultos en los formularios Web. Por lo general estos campos contienen datos que envía el
servidor, son invisibles y no ocupan espacio en la página Web. En el ejemplo sobre ver información
del estudiante, la clase :Controlador interfaz ver estudiante agregó un campo oculto que contiene
el numeroEstudiante al formulario paginaWebEstudiante junto con el botonSiguiente. Cuando el
estudiante hace clic en el botonSiguiente, se envía el numeroEstudiante al servidor y el :Controlador
interfaz ver estudiante sabe para cuál estudiante debe obtener la información sobre el curso y la
calificación. Los datos en formularios ocultos no se guardan de una sesión a otra del navegador, por lo que
se mantiene la privacidad.
Las capas de presentación, negocios y persistencia en los diagramas de secuencia
En el ejemplo anterior mostramos todas las clases en el mismo diagrama. Al escribir código para sistemas es útil
analizar los diagramas de secuencia como si tuvieran tres capas:
1. La capa de presentación, que representa lo que ve el usuario. Esta capa contiene las clases de interfaz o de
límite.
2. La capa de negocios, que contiene las reglas únicas para esta aplicación. Esta capa contiene las clases de
control.
3. La capa de persistencia o acceso a los datos, que describe la forma de obtener y almacenar los datos. Esta
capa contiene las clases de entidad.
Lo ideal sería escribir código de programa separado para cada una de estas capas.
Con la introducción de Ajax, las líneas se volvieron borrosas. Ajax, un acrónimo para JavaScript y XML
asíncrono, es una colección de técnicas que permiten a las aplicaciones Web recuperar información del servidorwww.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 303
sin alterar la visualización de la página actual. Esto resulta ser una ventaja debido a que no hay que volver a car-
gar toda la página Web si recibimos datos adicionales del servidor.
Antes de la creación de Ajax, el usuario que visitaba una página Web respondía algunas preguntas mediante
la introducción de datos en un formulario basado en Web y después tenía que esperar hasta que se cargara una
nueva página. Esto era necesario debido a que el código para validar, obtener los datos y después responder al
usuario residía en el servidor. Con la llegada de Ajax, la página Web se actualiza con rapidez debido a que gran
parte del proceso de validación y demás lógica de control se incluye ahora en el código de JavaScript del nave-
gador o del lado del cliente. Esto significa que las reglas de negocios se incluyen tanto en la clase de límite como
en la clase de control, por lo que no es posible tener tres capas.
CÓMO MEJORAR LOS DIAGRAMAS DE CLASES
Los símbolos de clases también se pueden usar en los diagramas de clases y de comunicación. La figura
10.16 ilustra el diagrama de clases para un estudiante que ve su información personal y del curso en páginas
Web. Cada clase tiene atributos y métodos (los cuales no se muestran en los diagramas que utilizan esta no-
tación).
Si la clase es de tipo interfaz de usuario, los atributos son los controles (o campos) en la pantalla o formu-
lario. Los métodos serían los que trabajan con la pantalla, como enviar o restablecer. También podrían ser Java-
Script para una página Web, ya que el código trabaja de manera directa con la página Web.
Si la clase es una clase de control, los atributos serían aquellos que se necesitan para implementar la clase,
como las variables que se utilizan sólo en la clase de control. Los métodos serían aquellos utilizados para realizar
cálculos, tomar decisiones y enviar mensajes a otras clases.
Si la clase es una clase de entidad, los atributos representan a los atributos almacenados para la entidad y
los métodos que trabajan directamente con la entidad, como crear una instancia, modificar, eliminar, obtener o
imprimir.
Los sitios Web pueden usar una combinación de muchas clases para cumplir con los objetivos de
usuario. Por ejemplo, un sitio Web puede usar JavaScript para realizar una validación previa de los datos
y después pasarlos a las clases de control del servidor que realizan una validación detallada, incluyendo
la obtención de los datos. A su vez, las clases de control del servidor pueden enviar JavaScript de vuelta a la
página Web para aplicar cierto formato. Es muy común que una aplicación Web involucre a muchas clases,
algunas de las cuales contienen sólo una línea de código, en un método para poder lograr el objetivo de la
reutilización.
Estudiante
:Estudiante :Curso
:Controlador
interfaz ver
estudiante
:Seccion
:Calcular
promedio
calificacion
:Interfaz de
usuario ver
estudiante
FIGURA 10.16
Un diagrama de clases para la
paginaWebEstudiante que utiliza
símbolos de clase especiales.www.xlibros.com

304 PARTE III • EL PROCESO DE ANÁLISIS
Relaciones
Otra manera de mejorar los diagramas de clases es mostrar las relaciones. Éstas son conexiones entre las clases,
de manera similar a las que se encuentran en un diagrama de entidad-relación. Las relaciones se muestran como
líneas que conectan a las clases en un diagrama de clases. Hay dos categorías de relaciones: asociaciones y rela-
ciones entre un todo y sus partes.
ASOCIACIONES El tipo más simple de relación es una asociación, o conexión estructural entre clases u objetos.
Las asociaciones se muestran como una simple línea en un diagrama de clases. Los puntos finales de la línea se
etiquetan con un símbolo que indica la multiplicidad, que es lo mismo que la cardinalidad en un diagrama de
entidad-relación. Un cero representa ninguno, un uno representa uno y sólo uno; un asterisco representa muchos.
La notación 0..1 representa de cero a uno y la notación 1..* representa de uno a muchos. En la figura 10.17 se
muestran las asociaciones.
Estudiante graduado
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–especialidad
–numeroTesis
–consejero
+aceptarEstudiante()
+verEstudiante()
+cambiarEstudiante()
+graduarEstudiante()
Tesis
–numeroTesis
–numeroEstudiante
–tituloTesis
–fechaInicio
–fechaTerminacion
–fechaAprobacion
–aprobadaPor
+agregarTesis()
+cambiar()
+aprobarTesis()
1 1
tiene
Estudiante
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–especialidad
+inicializar()
+verEstudiante()
+cambiarEstudiante()
+graduarEstudiante()
Curso
–numeroCurso
–descripcionCurso
–numeroDeCreditos
–numeroDepartamento
+agregarCurso()
+cambiarCurso()
+buscarCurso()
1 1..
se inscribe en
Estudiante
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–especialidad
+inicializar()
+verEstudiante()
+cambiarEstudiante()
+graduarEstudiante()
Cuarto dormitorio
–nombreDormitorio
–numeroCuarto
–tamanioCuarto
–generoOcupante
–numeroVacantes
+agregarCuarto()
+cambiarCuarto()
+buscarCuarto()
+cambiarVacantes()
1 0..
se asigna a
Estudiante
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–especialidad
+inicializar()
+verEstudiante()
+cambiarEstudiante()
+graduarEstudiante()
Actividad voluntaria
–numeroActividad
–descripcionActividad
–organizacionActividad
–fechaActividad
–numeroEstudiante
+agregarActividad()
+cambiarActividad()
+buscarActividad()
+agregarVoluntario()
1
participa en
FIGURA 10.17
Tipos de asociaciones que pueden
ocurrir en los diagramas de clases.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 305
Los diagramas de clases no restringen el límite inferior para una asociación. Por ejemplo, una asocia-
ción podría ser 5..*, lo cual indica que debe haber un mínimo de 5 presentes. Lo mismo se aplica para los
límites superiores. Por ejemplo, el número de cursos en los que está inscrito actualmente un estudiante po-
dría ser 1..10, lo cual representa de 1 a 10 cursos. También se puede incluir un rango de valores separados
por comas, como 2, 3, 4. En el modelo de UML, las asociaciones por lo general se etiquetan con un nombre
descriptivo.
Las clases de asociaciones son aquellas que se utilizan para descomponer una asociación de muchos a mu-
chos entre las clases. Son similares a las entidades asociativas en un diagrama de entidad-relación. Estudiante y
Curso tienen una relación de muchos a muchos; para resolver esta relación se agrega una clase de asociación lla-
mada Seccion entre las clases de Estudiante y Curso. La figura 10.18 muestra una clase de asociación llamada
Seccion con una línea punteada conectada a la línea de la relación de muchos a muchos.
Un objeto en una clase puede tener una relación con otros objetos en la misma clase; a esto se le denomina
asociación reflexiva. Un ejemplo sería una tarea que tenga una tarea precedente, o un empleado que supervisa a
otro empleado. Esto se muestra como una línea de asociación que conecta a la clase consigo misma, con etique-
tas que indican los nombres de los roles, como tarea y tarea precedente.
RELACIONES ENTRE UN TODO Y SUS PARTES Estas relaciones se dan cuando una clase representa al objeto como
un todo y otras clases representan partes de ese objeto. El todo actúa como un contenedor para las partes. Para
mostrar estas relaciones en un diagrama de clases se utiliza una línea con un diamante en un extremo. El diamante
está conectado al objeto que es el todo. Las relaciones entre un todo y sus partes (así como la agregación, que
veremos más adelante) se muestran en la figura 10.19.
Una relación entre un todo y sus partes puede ser un objeto entidad que tenga partes distintas, como un sis-
tema computarizado que incluye computadora, impresora, pantalla, etc., o un automóvil que tiene un motor, sistema
de frenos, transmisión, etc. También es posible usar relaciones entre un todo y sus partes para describir una in-
terfaz de usuario en la que una pantalla de GUI contiene una serie de objetos como listas, cuadros o botones de
opción, o tal vez un encabezado, cuerpo y área del pie. Las relaciones entre un todo y sus partes tienen tres cate-
gorías: agregación, colección y composición.
Agregación Una agregación se describe comúnmente como una relación “tiene un”. La agregación provee el
medio para mostrar que todo el objeto está compuesto de la suma de sus partes (otros objetos). En el ejemplo
de inscripción de estudiantes, el departamento tiene un curso y el curso es para un departamento. Ésta es una
relación más débil, ya que tal vez el departamento cambie o se elimine y el curso puede seguir existiendo. Un
paquete de computadora tal vez ya no esté disponible, pero las impresoras y los demás componentes siguen
existiendo. El diamante al final de la línea de la relación no está relleno.
Colección Una colección consiste de un todo y sus miembros. Éste puede ser un distrito de votación con votantes
o una biblioteca con libros. Los votantes o libros pueden cambiar, pero el todo retiene su identidad. Ésta es una
asociación débil.
Estudiante
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–mayor
–menor
+cambiarEstudiante()
+buscarEstudiante()
+graduarEstudiante()
+inicializar()
+estudianteCompleto()
+verEstudiante()
Curso
–numeroCurso
–descripcionCurso
–numeroDeCreditos
–numeroDepartamento
+agregarCurso()
+cambiarCurso()
+buscarCurso()
Sección
–numeroEstudiante
–numeroCurso
–anio
–semestre
–calificacion
+agregarSeccion()
+cambiarCalificacion()
+inscribirEstudiante()
+registrarCalificacion()
+retirarEstudiante()
1.. 0..
tienetoma
FIGURA 10.18
Un ejemplo de una clase
asociativa en la que una sección
específica define la relación entre
un estudiante y un curso.www.xlibros.com

306 PARTE III • EL PROCESO DE ANÁLISIS
Composición La composición es una relación entre un todo y sus partes, donde el todo tiene una responsabilidad
por cada parte. Es una relación más fuerte y por lo general se muestra con un diamante relleno. Las palabras
clave para la composición son una clase “siempre contiene” a otra clase. Si el todo se elimina, todas las partes se
eliminan. Un ejemplo sería una política de seguros con cláusulas adicionales. Si se cancela la póliza también
se cancelan las cláusulas adicionales del seguro. En una base de datos se establecería la integridad referencial
para eliminar los registros hijos en cascada. En una universidad hay una relación de composición entre un
curso y una asignación, así como entre un curso y un examen. Si se elimina el curso se eliminan también las
asignaciones y los exámenes.
Diagramas de generalización/especialización (gen/spec)
Un diagrama de generalización/especialización (gen/spec) se puede considerar un diagrama de clases mejo-
rado. Algunas veces es necesario separar las generalizaciones de las instancias específicas. Como vimos al
principio de este capítulo, un oso koala es parte de una clase de marsupiales, que a su vez es parte de una
clase de animales. Algunas veces necesitamos diferenciar si un oso koala es un animal o si es un tipo de ani-
mal. Además, un oso koala puede ser un animal de peluche. Por lo tanto, a menudo es necesario aclarar estas
sutilezas.
GENERALIZACIÓN Una generalización describe una relación entre un tipo general de cosa y un tipo más
específico de cosa. Este tipo de relación se describe comúnmente como una relación “es un”. Por ejemplo, un
auto es un vehículo y un camión es un vehículo. En este caso, el vehículo es la cosa general, mientras que auto y
camión son las cosas más específicas. Las relaciones de generalización se utilizan para modelar la herencia y la
especialización de las clases. A una clase general se le conoce algunas veces como superclase, clase base o clase
padre; a una clase especializada se le llama subclase, clase derivada o clase hija.
HERENCIA Varias clases pueden tener los mismos atributos y/o métodos. Cuando esto ocurre, se crea una clase
general que contiene los atributos y métodos comunes. La clase especializada recibe o hereda los atributos
y métodos de la clase general. Además, la clase especializada tiene atributos y métodos únicos que sólo se
definen en ella. Al crear clases generalizadas y permitir que la clase especializada herede los atributos y métodos
ayudamos a fomentar la reutilización, ya que el código se utiliza muchas veces. Esto también ayuda a mantener
el código existente del programa. Así, el analista puede definir los atributos y métodos una vez, pero usarlos
muchas veces en cada clase heredada.
Estudiante
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–mayor
–menor
+cambiarEstudiante()
+buscarEstudiante()
+graduarEstudiante()
+inicializar()
+estudianteCompleto()
+verEstudiante()
Organización del campus
–numeroOrganizacion
–nombreOrganizacion
–tipoOrganizacion
–presidente
–tesorero
–secretario
–saldoCuenta
–numeroDeMiembros
+cambiar()
+cambiarOficiales()
+nuevo()
Actividad de recaudación
de fondos
–numeroActividad
–descripcionActividad
–tipoActividad
–montoGastado
–montoRecibido
–fechaCompletada
+cambiar()
+nuevo()
+registrarMonto()
FIGURA 10.19
Un ejemplo de relaciones entre un
todo y sus partes y de agregación.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 307
Una de las características especiales de la metodología orientada a objetos es la creación y el mantenimiento
de extensas bibliotecas de clases disponibles en muchos lenguajes. Por ejemplo, un programador que utilice Java,
.NET o C# tendrá acceso a una enorme cantidad de clases que ya se han desarrollado.
POLIMORFISMO El polimorfismo (que significa muchas formas) o redefinición de métodos (no es lo mismo
que sobrecarga de métodos) es la capacidad de un programa orientado a objetos de tener varias versiones de
un mismo método con el mismo nombre dentro de una relación superclase/subclase. La subclase hereda un
método padre pero le puede agregar elementos o modificarlo. La subclase puede cambiar el tipo de los datos, o
puede cambiar la forma en que trabaja el método. Por ejemplo, podría haber un cliente que reciba un descuento
adicional por volumen, con lo que se usaría un método modificado para calcular el total del pedido. Se dice que
el método de la subclase redefine al método de la superclase.
Cuando los atributos o métodos se definen más de una vez, se utiliza el más específico (el más bajo en la
jerarquía de clases). El programa compilado recorre la cadena de clases en busca de los métodos.
CLASES ABSTRACTAS Las clases abstractas son clases generales y se utilizan cuando se incluye la generalización/
especificación (gen/spec) en el diseño. La clase general se convierte en la clase abstracta. La clase abstracta no
tiene objetos directos o instancias de clase, y se utiliza sólo en conjunto con clases especializadas. Por lo general
las clases abstractas tienen atributos y pueden tener unos cuantos métodos.
La figura 10.20 es un ejemplo de un diagrama de clases de generalización/especificación. La flecha apunta
a la clase general, o superclase. A menudo las líneas que conectan dos o más subclases con una superclase se
Persona
–apellidoPaterno
–primerNombre
–calle
–apartamento
–ciudad
–estado
–cp
–telefono
–telCelular
–email
+cambiarDireccion()
+cambiarNombre()
Estudiante
–numeroEstudiante
–creditosCompletados
–calificacionPromedio
–departamento
–especialidad
–esmenor
+cambiarEstudiante()
+buscarEstudiante()
+graduarEstudiante()
+inicializar()
+estudianteCompleto()
+verEstudiante()
Empleado
–numeroEmpleado
–salario
–AAFBruto
–AAFRetencion
–fechaContratacion
–departamento
+cambiarEmpleado()
+imprimirInformacionImpuestos()
+producirChequeNomina()
puedeserun
esun
puedeserun
esun
Docente
–titulo
–puesto
–urlWeb
+cambiarPosicion()
+cambiarURL()
Administrador
–titulo
+cambiarEmpleado()
puedeserun
esun
puedeserun
esuntipode
FIGURA 10.20
Un diagrama de generalización/
especificación es una forma
refinada de un diagrama de clases.www.xlibros.com

308 PARTE III • EL PROCESO DE ANÁLISIS
unen mediante una flecha que apunta a la superclase, pero también se podrían mostrar como flechas separadas.
Observe que el nivel superior es Persona, la clase que representa a cualquier persona. Los atributos describen
cualidades que poseen todas las personas en la universidad. Los métodos permiten a la clase cambiar el nom-
bre y la dirección (incluyendo el teléfono y la dirección de correo electrónico). Ésta es una clase abstracta, sin
instancias.
Estudiante y Empleado son subclases ya que tienen distintos atributos y métodos. Un empleado no tiene una
calificación promedio y un estudiante no tiene un salario. Ésta es una versión simple y no incluye a los emplea-
dos que son estudiantes ni a los estudiantes que trabajan para la universidad. Si se agregaran, serían subclases de
las clases Empleado y Estudiante. Empleado tiene dos subclases, Docente y Administrador, ya que hay dis-
tintos atributos y métodos para cada una de estas clases especializadas.
Las subclases cuentan con verbos especiales para definirlas. A menudo son palabras seguidas, como esun
para “es un”, esuntipode para “es un tipo de” y puedeserun para “puede ser un”. No hay distinción entre “es un”
y “es una”; ambas utilizan esun.
esun Docente esun Empleado
esuntipode Administrador esuntipode Empleado
puedeserun Empleado puedeserun Docente
IDENTIFICAR CLASES ABSTRACTAS Tal vez pueda identificar las clases abstractas si encuentra varias clases o
tablas de base de datos que tengan los mismos elementos, o si varias clases tienen los mismos métodos. Podemos
crear una clase general al extraer los atributos y métodos comunes, o podríamos crear una clase especializada
para los atributos y métodos únicos. Si usamos un ejemplo bancario como un retiro, un pago sobre un préstamo o
la escritura de un cheque, todos tendrán el mismo método: restar dinero del saldo del cliente.
BUSCAR CLASES Hay varias formas de determinar las clases. Se pueden descubrir durante las sesiones de
entrevista o JAD (que vimos en el capítulo 4), durante las sesiones facilitadas del equipo o a partir de las
sesiones de lluvia de ideas. Al analizar documentos y memos también se pueden revelar clases. Una de
las formas más sencillas es usar el método CRC que vimos antes en este capítulo. El analista también debe
examinar los casos de uso en busca de sustantivos. Cada sustantivo puede generar un candidato a una clase
potencial. Se les llama clases candidatas debido a que algunos de los sustantivos pueden ser atributos de una
clase.
Cada clase debe existir para un objeto distinto que tenga una definición clara. Pregúntese qué conoce la
clase, los atributos; y qué es lo que la clase sabe cómo hacer, los métodos. Identifique las relaciones entre clases
y la multiplicidad para cada extremo de la relación. Si la relación es de muchos a muchos, cree una clase de in-
tersección o asociativa, similar a la entidad asociativa en un diagrama de entidad-relación.
DETERMINAR LOS MÉTODOS DE LAS CLASES El analista debe determinar los atributos y métodos de las clases.
Los atributos son fáciles de identificar, pero los métodos que trabajan con los atributos pueden ser más difíciles
de identificar. Algunos de los métodos son estándar y siempre están asociados con una clase, como new(), o el
método <<crear>>, que es una extensión para el UML creada por una persona u organización, a lo cual se le
conoce como estereotipo. Los símbolos << y >> no son simplemente pares de símbolos mayor que y menor que,
sino que se les conoce como paréntesis angulares.
Otra manera útil de determinar los métodos es examinar una matriz CRUD (vea el capítulo 7). La figura
10.21 muestra una matriz CRUD para los ofrecimientos de cursos. Cada letra requiere un método distinto. Si
hay una C para crear, se agrega un método new(). Si hay una U para actualizar, se agrega un método actualizar()
o cambiar(). Si hay una D para eliminar, se agrega un método eliminar() o quitar(). Si hay una R para leer, se
agregan métodos para buscar, ver o imprimir. En el ejemplo mostrado, la clase librotexto necesitaría un método
crear para agregar un libro de texto y un método leer para iniciar una consulta sobre un curso, cambiar un libro
de texto o buscar un libro de texto. Si se reemplazara un libro de texto se necesitaría un método actualizar, y si se
quitara un libro de texto se requeriría un método eliminar.
MENSAJES Para poder lograr un trabajo útil, la mayoría de las clases necesitan comunicarse entre sí. La
información se puede enviar mediante un objeto en una clase a un objeto en otra clase a través de un mensaje,
en forma similar a una llamada en un lenguaje de programación tradicional. Un mensaje también actúa como
comando para indicar a la clase receptora que haga algo. Un mensaje consiste en el nombre del método en la
clase receptora, así como los atributos (parámetros o argumentos) que se pasan con el nombre del método. La clase
receptora debe tener un método que corresponda al nombre del mensaje.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 309
Actividad Departamento Curso Librotexto Examen
Agregar departamento C
Ver departamento
Agregar curso
C
Cambiar curso
RU
Consulta de curso R R R R
R
C
U
R
RAgregar libro de texto
Cambiar libro de texto R
R
R
R
R
R
Buscar libro de texto
Eliminar libro de texto R
Agregar asignación R
Cambiar asignación R
Asignacion
D
C
RU
Cambiar asignación R R
Ver asignación R R
Agregar examen R RU
Cambiar examen R R
FIGURA 10.21
Se puede usar una matriz CRUD
para ayudar a determinar qué
métodos se necesitan. Esta matriz
CRUD se utiliza para determinar
los métodos y las operaciones
para los ofrecimientos de cursos.
Como los mensajes se envían de una clase a otra, se pueden considerar como entrada o salida. La primera
clase debe proveer los parámetros incluidos con el mensaje y la segunda clase utiliza esos parámetros. Si existe
un diagrama de flujo de datos hijo físico para el dominio del problema, puede ser útil para descubrir métodos. El
flujo de datos de un proceso primitivo a otro representa el mensaje y hay que examinar los procesos primitivos
como candidatos a métodos.
DIAGRAMAS DE ESTADOS
El diagrama de estados, o de transiciones de estado, es otra herramienta para determinar los métodos de las cla-
ses. Se utiliza para examinar los distintos estados que puede tener un objeto.
Se crea un diagrama de estados para una sola clase. Por lo general los objetos se crean, pasan por cambios y
se eliminan o quitan.
Los objetos existen en estos diversos estados, que son las condiciones de un objeto en un momento especí-
fico. Los valores del atributo de un objeto definen el estado en que se encuentra el objeto y algunas veces hay
un atributo tal como Estado del pedido (pendiente, en recolección, empaquetado, enviado, recibido, etcétera) que
indica el estado. Un estado tiene un nombre en el que cada palabra empieza con mayúscula. El nombre debe ser
único y descriptivo. Un estado también tiene acciones de entrada y de salida: las cosas que el objeto debe hacer
cada vez que entra o sale de un estado específico.
Un evento es algo que ocurre en un tiempo y lugar específicos. Los eventos provocan un cambio del
estado del objeto y se dice que una transición se “dispara”. Los estados separan eventos, como un pedido
que espera a ser llenado, y los eventos separan estados, como un evento Pedido recibido o un evento Pedido
completo.
Un evento produce la transición y ocurre cuando se cumple una condición de guardia. Esta condición de
guardia es algo que se evalúa como verdadero o falso y puede ser tan simple como “Hacer clic para confirmar el
pedido”. También puede ser una condición que ocurra en un método, como un elemento que esté agotado. Las
condiciones de guardia se muestran entre corchetes a un lado de la etiqueta del evento.www.xlibros.com

310 PARTE III • EL PROCESO DE ANÁLISIS
Además hay eventos diferidos, o eventos que se retienen hasta que un objeto cambia a un estado que pueda
aceptarlos. Un usuario que teclea algo cuando un procesador de palabras realiza un respaldo sincronizado es un ejem-
plo de un evento diferido. Una vez que se completa el respaldo sincronizado, el texto aparece en el documento.
Los eventos se clasifican en tres categorías distintas:
1. Señales o mensajes asíncronos, que ocurren cuando el programa que hace la llamada no espera un mensaje
de retorno, como una característica que se opera desde un menú.
2. Mensajes sincrónicos, que son llamadas a funciones o subrutinas. El objeto que hace la llamada se detiene y
espera a que se le regrese el control, junto con un mensaje opcional.
3. Eventos temporales, que ocurren en un tiempo predeterminado. Por lo general no involucran a un actor o a
un evento externo.
Los objetos materiales tienen persistencia; es decir, existen durante un extenso periodo de tiempo. Los
vuelos de aviones, conciertos y eventos deportivos tienen una persistencia más corta (pueden tener estados que
cambian en un tiempo más corto). Algunos objetos, conocidos como objetos transitorios, no sobreviven al final
de una sesión. Éstos incluyen la memoria principal, los datos de una URL (o ubicación) Web, las páginas Web,
pantallas CICS, etcétera. La única forma de guardar los objetos transitorios es almacenar la información sobre
ellos, como cuando se guardan los datos Web en una cookie.
Cada vez que un objeto cambia de estado, algunos de los atributos cambian sus valores. Además, cada vez
que cambian los atributos de un objeto, debe haber un método para cambiar esos atributos. Cada uno de los mé-
todos necesitaría una pantalla o formulario Web para agregar o modificar los atributos. Éstos se convierten en
los objetos de interfaz. Comúnmente la pantalla o formulario Web contiene más controles (o campos) que los
atributos que cambian. Por lo general tienen claves primarias, información de identificación (como un nombre o
dirección) y otros atributos necesarios para una buena interfaz de usuario. La excepción es un evento temporal,
que puede usar tablas de la base de datos o una cola para contener la información.
Ejemplo de una transición de estado
Veamos el ejemplo de un estudiante que se inscribe en una universidad y los diversos estados por los que pasaría.
A continuación le mostramos una lista detallada de tres de esos estados:
Los otros estados son Estudiante Programa, Estudiante Actual, Estudiante Continuo y Estudiante Gra-
duado. A cada estado hay que asociar un evento, métodos, atributos modificados y una interfaz de usuario. Po-
demos usar esta serie de estados para determinar los atributos y métodos que forman parte de la clase.
Los estados y eventos que desencadenan los cambios se pueden representar en un diagrama de estados (o en
un diagrama de transiciones de estado). En la figura 10.22 se muestra el diagrama de estados para Estudiante.
Estado: Estudiante potencial
Evento: Aplicación enviada
Método: new()
Atributos modificados: Numero
Nombre
Direccion
Interfaz de usuario: Formulario Web Solicitud de
estudiante
Estado: Estudiante Aceptado
Evento: Requerimientos cumplidos
Método: aceptarEstudiante()
Atributos modificados: Fecha de admisión
Estado del estudiante
Devolver carta de aceptación
Interfaz de usuario: Pantalla Aceptar estudiante
Estado: Dormitorio Asignado Estudiante
Evento: Dormitorio seleccionado
Método: asignarDormitorio()
Atributos modificados: Nombre del dormitorio
Cuarto del dormitorio
Plan de comidas
Interfaz de usuario: Pantalla Asignar dormitorio a
estudiantewww.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 311
Los estados se representan mediante rectángulos y los eventos o actividades son las flechas que enlazan los es-
tados y hacen que un estado cambie a otro estado. Los eventos de transición se nombran en pasado, porque ya
ocurrieron para crear la transición.
No hay que crear diagramas de estados para todas las clases. Se crean cuando:
1. Una clase tiene un ciclo de vida complejo.
2. Una instancia de una clase puede actualizar sus atributos en varias formas durante el ciclo de vida.
3. Una clase tiene un ciclo de vida operacional.
4. Dos clases dependen una de la otra.
5. El comportamiento actual del objeto depende de lo que ocurrió antes.
Al examinar un diagrama de estados, aproveche la oportunidad para buscar errores y excepciones. Inspec-
cione el diagrama para detectar si los eventos ocurren en un tiempo inadecuado. Verifique también que se hayan
representado todos los eventos y estados. En los diagramas de estados sólo hay que evitar dos problemas: verifi-
que que no entren todas las transiciones en un estado o que salgan todas de éste.
Cada estado debe tener por lo menos una transición de entrada y de salida. Algunos diagramas de es-
tados usan los mismos símbolos de inicio y terminación que los que utiliza un diagrama de actividad: un
círculo relleno para representar el inicio y círculos concéntricos con el centro relleno para indicar el fin del
diagrama.
PAQUETES Y OTROS ARTEFACTOS DE UML
Los paquetes son contenedores para otras cosas de UML, como los casos de uso o las clases. Los paquetes pue-
den mostrar el particionamiento del sistema, para indicar qué clases o casos de uso se agrupan en un subsistema,
a lo cual se le denomina paquetes lógicos. También pueden ser paquetes componentes, que contienen componen-
Estudiante
Potencial
Estudiante
Aceptado
se envió
solicitud
se cumplieron
los requerimientos
se seleccionó
el dormitorio
se inscribió el
estudiante en la
clase
Dormitorio
Asignado
Estudiante
se seleccionó
el programa
Estudiante
Programa
se completaron los
requerimientos de
graduación
Estudiante
Actual
se completó el
curso con
éxito
el estudiante
se inscribió
en la clase
se graduó
el estudiante
Estudiante
Graduado
Estudiante
Continuo
FIGURA 10.22
Un diagrama de estados donde se
muestra cómo un estudiante
progresa de estudiante potencial a
estudiante graduado.www.xlibros.com

312 PARTE III • EL PROCESO DE ANÁLISIS
tes físicos del sistema, o paquetes de casos de uso que contienen un grupo de casos de uso. Los paquetes usan un
símbolo de carpeta con el nombre del paquete en la ficha de la carpeta o centrado en la misma. El empaqueta-
miento puede ocurrir durante el análisis del sistema o en una etapa posterior de diseño del sistema. Los paquetes
también pueden tener relaciones de manera similar a los diagramas de clases, que pueden incluir asociaciones y
herencia.
La figura 10.23 es un ejemplo de un diagrama de paquetes de casos de uso. Muestra que cuatro casos de uso,
Agregar estudiante, Inscribirse en clase, Transferir créditos y Ver información de estudiante son parte del
paquete Estudiante. Hay tres casos de uso, Agregar docente, Ver información de docente y Asignar docente
a curso que forman parte del paquete Docente.
A medida que continúe construyendo diagramas le será conveniente utilizar los diagramas de componentes,
los diagramas de despliegue y las cosas de anotaciones. Éstos permiten distinta perspectivas sobre el trabajo a
realizar.
El diagrama de componentes es similar a un diagrama de clases, sólo que es más como una vista superficial
de la arquitectura del sistema. El diagrama de componentes muestra los componentes del sistema, como un ar-
chivo de clase, un paquete, las bibliotecas compartidas, una base de datos, etcétera, y la forma en que se relacio-
nan entre sí. Los componentes individuales en un diagrama de componentes se consideran con más detalle dentro
de otros diagramas de UML, como los diagramas de clases y los diagramas de casos de uso.
El diagrama de despliegue ilustra la implementación física del sistema, incluyendo el hardware, las relacio-
nes entre el hardware y el sistema en el que se va a desplegar. El diagrama de despliegue puede mostrar los ser-
vidores, estaciones de trabajo, impresoras, etcétera.
Las cosas de anotaciones proveen a los desarrolladores más información sobre el sistema. Estas cosas con-
sisten en notas que se pueden unir a cualquier cosa en UML: objetos, comportamientos, relaciones, diagramas
o cualquier cosa que requiera descripciones detalladas, suposiciones o cualquier información relevante para el
diseño y la funcionalidad del sistema. El éxito del UML depende de la documentación completa y precisa de
nuestro modelo del sistema para proveer toda la información que sea posible al equipo de desarrollo. Las notas
proveen una fuente de conocimiento y comprensión común sobre su sistema para ayudar a que sus desarrollado-
res estén coordinados. Las notas se muestran como un símbolo de un papel con una esquina doblada y una línea
que las conecta con el área que necesita más detalles.
Departamento
Miembro del cuerpo
docente
Estudiante
Oficina financiera
Registro
Estudiante
Administración
Ver información
de docente
Agregar
estudiante
Transferir
créditos
Inscribirse
en clase
Ver información
de estudiante
Agregar
docente
Asignar docente
a curso
Estudiante
Docente
FIGURA 10.23
Los casos de uso se pueden
agrupar en paquetes.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 313
PONGA EL UML A TRABAJAR
El UML provee un útil conjunto de herramientas para el análisis y diseño de sistemas. Al igual que con cual-
quier producto creado con la ayuda de herramientas, el valor de los entregables de UML en un proyecto de-
pende de la experiencia con la que el analista de sistemas maneje las herramientas. En un principio el analista
usará el conjunto de herramientas de UML para descomponer los requerimientos del sistema en un modelo de
O P O R T U N I D A D D E C O N S U L T O R Í A 1 0 . 3
Desarrollo de un sistema fino cuyo plazo de entrega
se venció hace mucho: uso del análisis orientado a objetos
para el Sistema de la biblioteca pública Ruminski*
M ientras Dewey Dezmal entra a la sala de lectura de techos
altos y paneles de madera de la Biblioteca Pública Ruminski, una
joven sentada en una larga mesa de roble asoma su cabeza por
encima de un monitor, lo ve y al pararse dice: “Bienvenido, soy
Peri Otticle, directora de la biblioteca. Entiendo que está usted
aquí para ayudarnos a desarrollar nuestro nuevo sistema de infor-
mación”.
Intimidado aún por la belleza del antiguo edificio de la biblio-
teca y la yuxtaposición de tanta tecnología y tanta historia, Dewey
se presenta como analista de sistemas con una pequeña empresa de
consultoría de TI, People and Objects, Inc.
“Es la primera vez que me asignan a este tipo de proyecto,
aunque en realidad es interesante para mí, ya que me gradué de la
Information Studies School en la Upstate University. Hay especia-
lizaciones en ciencias bibliotecarias o TI, por lo que muchos de mis
compañeros entraron a trabajar en bibliotecas públicas; yo opté por
el grado de TI”.
“Entonces vamos a trabajar bien juntos”, dice Peri. “Vamos a
mi oficina para no molestar a los usuarios y poder enseñarte un in-
forme que escribí”.
Al pasar por la bella escalera en espiral, al parecer esculpida
en madera, Peri observa que Dewey ve los alrededores y dice: “Tal
vez te preguntes sobre la magnificencia del edificio, ya que somos
una institución pública. Somos afortunados. Nuestro benefactor es
Valerian Ruminski. De hecho, ha donado tanto dinero a tantas bi-
bliotecas que el personal lo llama afectuosamente “Valerian el Bi-
bliotecario”.
Después de pasar varios usuarios, Peri continúa: “Como pue-
des ver, es un lugar muy concurrido. Y sin importar nuestro antiguo
entorno, no estamos detenidos en el pasado”.
Dewey lee el reporte que le entrega Peri. Una sección extensa
se titula “Resumen de los principales requerimientos de los usua-
rios” y la lista en viñetas dice:
Un usuario de la biblioteca que esté registrado en el sistema
puede sacar libros y revistas del sistema.
El sistema de la biblioteca debe revisar en forma periódica
(por lo menos una vez a la semana) si se venció la fecha de
entrega de un ejemplar de un libro o publicación
especializada que un usuario haya sacado. De ser así se
enviará un aviso al usuario.
Un usuario puede reservar un libro o publicación
especializada que se encuentre prestada o que esté en proceso
de compra. La reservación se cancelará cuando el usuario
saque el libro o publicación especializada, o por medio de un
servicio de cancelación formal.
Al tiempo que deja de ver el informe, Dewey dice a Peri: “Estoy
empezando a entender los requerimientos del usuario. Veo muchas
similitudes entre mi antigua biblioteca universitaria y ésta. Pero el
tema que no vi que cubrieras fue el de cómo decidir qué es lo que la
biblioteca debe recolectar y qué es lo que debe desechar”.
Peri sonríe y contesta: “Es una pregunta intuitiva. El personal de
la biblioteca maneja la compra de nuevos libros y publicaciones es-
pecializadas para la biblioteca. Si algo es popular se compran más de
dos copias. Podemos crear, actualizar y eliminar información sobre
los títulos y copias de los libros y publicaciones especializadas, usua-
rios, préstamo de materiales y reservaciones en el sistema”.
Dewey deja de ver su libreta de anotaciones y dice: “Aún estoy
un poco confundido. ¿Cuál es la diferencia entre los términos título
y ejemplar?”.
Peri responde: “La biblioteca puede tener varios ejemplares de
un título. El título por lo general se refiere al nombre de un libro o
publicación especializada. Son los ejemplares de un libro los que se
sacan de la biblioteca”.
Con base en la entrevista de Dewey con Peri y la descripción
de requerimientos en su informe, así como en su propia experiencia
con el uso de los servicios de bibliotecas, use UML para responder
a las siguientes preguntas (Nota: Es importante que se asegure de
que sus soluciones sean lógicas y funcionales; establezca sus supo-
siciones con claridad siempre que sea necesario):
1. Dibuje un diagrama de casos de uso para representar a los
actores y los casos de uso en el sistema.
2. Describa los pasos para cada caso de uso (como hicimos para
organizar los casos de uso).
3. Describa escenarios para los pasos. En otras palabras, cree un
usuario y escriba un ejemplo del usuario a medida que
recorre cada paso.
4. Desarrolle una lista de cosas.
5. Cree diagramas de secuencia para los casos de uso con base
en los pasos y escenarios.
6. Complete el diagrama de clases; determine las relaciones
entre las clases y defina los atributos y métodos de cada
clase. Use la cosa de agrupamiento llamada paquete para
simplificar el diagrama de clases.
* Basado en un problema escrito por el Dr. Wayne Huang.www.xlibros.com

314 PARTE III • EL PROCESO DE ANÁLISIS
casos de uso y en un modelo de objetos. El modelo de casos de uso describe los casos de uso y los actores. El
modelo de objetos describe los objetos y sus asociaciones, además de las responsabilidades, colaboradores y
atributos de los objetos.
1. Defina el modelo de casos de uso.
Busque los actores en el dominio del problema; revise los requerimientos del sistema y entreviste algunos•
expertos de negocios.
Identifique los eventos principales iniciados por los actores y desarrolle un conjunto de casos de uso•
primarios en un nivel muy alto, que describan los eventos desde la perspectiva de cada actor.
Desarrolle los diagramas de casos de uso para comprender cómo se relacionan los actores con los casos•
de uso que definirán el sistema.
Refine los casos de uso primarios para desarrollar una descripción detallada de la funcionalidad del•
sistema para cada caso de uso primario. Provea detalles adicionales al desarrollar los escenarios de casos
de uso que documenten los flujos alternos de los casos de uso primarios.
Revise los escenarios de casos de uso con los expertos del área de negocios para verificar los procesos e•
interacciones. Haga las modificaciones necesarias hasta que los expertos del área de negocios estén de
acuerdo en que los escenarios de los casos de uso son completos y precisos.
2. Continúe con la creación de diagramas de UML para modelar el sistema durante la fase de análisis de
sistemas.
Derive los diagramas de actividad a partir de los diagramas de casos de uso.•
Desarrolle los diagramas de secuencia y de comunicación a partir de los escenarios de los casos de uso.•
Revise los diagramas de secuencia con los expertos del área de negocios para verificar los procesos y las•
interacciones. Haga las modificaciones necesarias hasta que los expertos del área de negocios estén de
acuerdo en que los diagramas de secuencia son completos y precisos. Con frecuencia, la revisión
adicional de los diagramas de secuencia gráficos provee a los expertos del área de negocios la
oportunidad de reconsiderar y refinar los procesos con un detalle más atómico que la revisión de los
escenarios de los casos de uso.
3. Desarrolle los diagramas de clases.
Busque los sustantivos en los casos de uso y haga una lista. Son objetos potenciales. Una vez que•
identifique los objetos, busque similitudes y diferencias en los objetos debido a sus estados o
comportamiento y después cree las clases.
Defina las principales relaciones entre las clases. Busque las relaciones “tiene un” y “es un” entre las•
clases.
Examine los diagramas de casos de uso y de secuencias para poder determinar las clases.•
Empezando con los casos de uso que son los más importantes para el diseño del sistema, cree los•
diagramas de clases que muestren las clases y relaciones que existen en los casos de uso. Un diagrama de
clases puede representar a las clases y relaciones descritas en varios casos de uso relacionados.
4. Dibuje diagramas de estados.
Desarrolle diagramas de estados para ciertos diagramas de clase, de manera que pueda proveer un análisis•
más detallado del sistema en este punto. Use los diagramas de estados como ayuda para comprender los
procesos complejos que no se puedan derivar por completo de los diagramas de secuencia.
Determine los métodos al examinar los diagramas de estados. Derive los atributos de las clases de los•
estados (datos) a partir de los casos de uso, expertos de las áreas de negocios y métodos de las clases.
Indique si los métodos y atributos de la clase son públicos (acceso externo) o privados (acceso interno
para la clase). Los diagramas de estados son en extremo útiles para modificar los diagramas de clases.
5. Empiece el diseño de sistemas; refine los diagramas de UML y utilícelos para derivar las clases y sus
atributos y métodos.
Revise todos los diagramas de UML existentes para el sistema. Escriba especificaciones de clases para•
cada clase que incluyan los atributos, métodos y descripciones de la clase. Revise los diagramas de
secuencia para identificar otros métodos de clases.
Desarrolle especificaciones de métodos que muestren con detalle los requerimientos de entrada y de•
salida para el método, junto con una descripción detallada del procesamiento interno del método.
Cree otro conjunto de diagramas de secuencia (si es necesario) para reflejar los métodos reales de las•
clases, además las interacciones entre las clases y las interfaces del sistema.
Cree diagramas de clases mediante los símbolos de clase especializados para la clase de límite o de•
interfaz, la clase de entidad y la clase de control.
Analice los diagramas de clases para derivar los componentes del sistema; es decir, clases relacionadas en•
función y lógica que se compilarán y desplegarán en conjunto como un archivo .DLL, .COM, un objeto,
un Java Bean, un paquete, etcétera.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 315
Desarrolle diagramas de despliegue para indicar cómo se desplegarán los componentes de su sistema en•
el entorno de producción.
6. Documente el diseño de su sistema en forma detallada. Este paso es imprescindible. Entre más completa sea
la información que provea al equipo de desarrollo por medio de la documentación y los diagramas de UML,
más rápido será el desarrollo y más sólido será el sistema de producción final.
LA IMPORTANCIA DE USAR UML PARA EL MODELADO
El UML es una potente herramienta que puede mejorar en forma considerable la calidad de su análisis y diseño
de sistemas, y se espera que las prácticas mejoradas se traduzcan en sistemas de mayor calidad.
Al usar el UML en forma iterativa en el análisis y el diseño podemos lograr una mejor comprensión entre
el equipo de negocios y el equipo de TI en relación con los requerimientos del sistema y los procesos que deben
ocurrir en el sistema para cumplir con esos requerimientos.
La primera iteración del análisis debe realizarse a un nivel muy alto para identificar los objetivos del sistema
en general y validar los requerimientos a través del análisis de casos de uso. Identificar los actores y definir el
modelo de casos de uso inicial son actividades que forman parte de esta primera iteración. Las iteraciones subsi-
guientes del análisis refinan más los requerimientos del sistema por medio del desarrollo de escenarios de casos
de uso, diagramas de clases, diagramas de secuencia, diagramas de estado, etcétera. Cada iteración requiere una
vista cada vez más detallada del diseño del sistema, hasta que las cosas y relaciones en el sistema se definan con
claridad y precisión en los documentos de UML.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 0 . 4
C-Shore
“!Ellos quieren que el núcleo de la interfaz de usuario de los
representantes de servicio al cliente se vuelva a programar por
completo!” exclama Bradley Vargo, director de desarrollo de siste-
mas de información en C-Shore Mutual Funds. “Hace tan sólo ocho
meses completamos un proyecto de desarrollo de dos años del Sis-
tema de representantes de servicio al cliente, CSR. Durante todo el
proyecto soportamos un desfile de requerimientos cambiantes.
Cada mes, los del departamento de marketing inventaban alguna
característica nueva y competitiva de servicio al cliente y, en una
semana, el grupo de CSR estaba aquí con grandes cambios en las
especificaciones del sistema CSR. ¡Pensé que nunca terminaríamos
ese proyecto! Ahora parece que tendremos que empezar un nuevo
proyecto de reprogramación en un sistema que tiene menos de un
año. ¡Pronosticamos una vida de 7 años para este sistema! Creo que
ahora inicia la etapa de la eterna reconstrucción”.
Bradley habla con Rachael Ciupek, la analista de sistemas de
aplicación en jefe responsable del sistema CSR y con Bridget Ciu-
pek, su hermana y la programadora que escribió la mayor parte de
la interfaz de usuario. “Cálmate, Bradley”, dice Rachael. “No es
culpa de los niños de marketing o de CSR. La naturaleza de nuestro
negocio se ha visto afectada por la competencia a ritmo veloz. Mar-
keting no inventa estos cambios para salir del aburrimiento. A me-
nudo responden a los nuevos servicios para el cliente basados en
computadora que ofrece nuestra competencia. Tenemos que perma-
necer en la punta o por lo menos seguirles el ritmo, ¡de lo contrario
estaremos buscando nuevos empleos!”.
“Bradley, Rachael, creo que ustedes saben mejor que nadie que
la situación puede ser peor de lo que creen”, interviene Bridget. “De
todas formas los programadores han estado realizando pequeñas
modificaciones en la interfaz de usuario durante los últimos ocho
meses. Los usuarios de CSR han estado hablando con nosotros di-
rectamente para suplicar ayuda. Por lo general sólo quieren un pe-
queño cambio en una parte aislada del sistema, pero esto ha creado
una carga de trabajo adicional debido a que tenemos que volver a
certificar todo el sistema. Ustedes saben cómo los efectos de una
pequeña modificación se pueden propagar a través de un programa
extenso. Hemos facturado el tiempo para el mantenimiento del
programa basándonos en el supuesto de que sólo estábamos ha-
ciendo pequeños ajustes al sistema completo. Aunque los cambios
han sido graduales, en ocho meses hemos vuelto a escribir aproxi-
madamente una cuarta parte del código de la interfaz de usuario de
CSR. El trabajo no ha decaído. Es bastante estable aún”.
“Entonces lo que me quieres decir”, dice Bradley, “es que te-
nemos necesidades del sistema en esta área que han estado cam-
biando en forma constante mientras tratábamos de escribir las
especificaciones, escribir el código del programa y crear un trabajo
con soluciones fijas contra un problema fluido. ¿Cómo podemos
escribir programas si durarán sólo unos cuantos meses sin que re-
quieran de un costoso mantenimiento?”.
¿Cómo puede Bradley administrar un proceso de desarrollo de
sistemas que ya no tenga procesos de negocios fijos o constantes
como parte de su conjunto de objetivos? ¿Hay una forma en que
Rachael administre los costos de mantenimiento de control y de las
especificaciones cuando se pide constantemente a los programado-
res que modifiquen partes aisladas de un programa extenso? Tenga
en cuenta que un objetivo importante es proveer un buen soporte
para las necesidades de los usuarios y las estrategias de negocios de
la organización.www.xlibros.com

316 PARTE III • EL PROCESO DE ANÁLISIS
Cuando esté completo su proceso de análisis y diseño, deberá tener un conjunto preciso y detallado de es-
pecificaciones para clases, escenarios, actividades y secuencias en el sistema. En general, podemos relacionar la
minuciosidad del análisis y diseño de un sistema con la cantidad de tiempo requerido para desarrollar el sistema
y la calidad resultante del producto entregado.
Lo que se pasa por alto con frecuencia en el desarrollo de un nuevo sistema es que entre más progrese un
proyecto, más costosas serán las modificaciones en los requerimientos de negocios de un sistema. Es mucho
más fácil, rápido y mucho menos costoso modificar el diseño de un sistema mediante el uso de una herramienta
CASE, o incluso en papel, durante las fases de análisis y diseño de un proyecto, que hacerlo durante la fase de
desarrollo.
Por desgracia algunos empleadores tienen poca visión y creen que sólo cuando un programador o analista
está codificando es cuando realmente está trabajando. Algunos empleadores asumen equivocadamente que la
productividad del programador se puede juzgar tan sólo con base en la cantidad de código producido, sin recono-
cer que la creación de diagramas ahorra en última instancia tiempo y dinero que de otra manera se desperdiciaría
si se hiciera un prototipo del proyecto sin una planificación apropiada.
En esta situación se adapta muy bien la analogía para la construcción de una casa. Aunque contratamos un
constructor para ello, no vamos a querer vivir en una estructura construida sin planeación, una en la que los cuar-
tos y características se agreguen al azar sin relación con la función o con el costo. Queremos que un constructor
construya el diseño que acordamos a partir de los planos de construcción, con las especificaciones que revisaron
con cuidado todas las partes involucradas. Como un miembro de un equipo de análisis dijo con tanta certeza:
“Poner un proyecto en papel antes de codificarlo reducirá su costo a la larga. Es mucho más económico borrar un
diagrama que modificar la codificación”.
Cuando cambian los requerimientos de negocios durante la fase de análisis, a veces es necesario volver a
dibujar algunos diagramas de UML. Pero si los requerimientos de negocios cambian durante la fase de desarro-
llo, tal vez se requiera una cantidad considerable de tiempo y dinero para rediseñar, recodificar y reevaluar el
sistema. Al confirmar su análisis y diseño en papel (en especial mediante el uso de diagramas de UML) con los
usuarios que son expertos en el área de negocios, usted ayudará a asegurar que se cumpla con los requerimientos
de negocios correctos cuando el sistema esté completo.
RESUMEN
Los sistemas orientados a objetos describen las entidades como
objetos. Los objetos forman parte de un concepto general co-
nocido como clases, la unidad principal de análisis en el análi-
sis y diseño orientados a objetos. Cuando se introdujo por
primera vez la metodología orientada a objetos, los defensores
citaron la reutilización de los objetos como el principal benefi-
cio de su metodología. Aunque la reutilización es el principal
objetivo, también es muy importante el mantenimiento de los
sistemas.
Los analistas pueden usar tarjetas CRC para empezar el
proceso de modelado de objetos de una manera informal. Se
puede agregar el Pensamiento en objetos a las tarjetas CRC para
ayudar al analista a refinar las responsabilidades en tareas cada
vez más pequeñas. Se pueden realizar sesiones CRC con un
grupo de analistas para determinar las clases y responsabilidades
en forma interactiva.
El lenguaje unificado de modelado (UML) provee un con-
junto estandarizado de herramientas para documentar el análi-
sis y diseño de un sistema de software. El UML se basa
fundamentalmente en una técnica orientada a objetos conocida
como modelado de casos. Un modelo de casos de uso describe
qué hace el sistema sin describir cómo lo hace. Un modelo de
casos de uso particiona la funcionalidad del sistema en com-
portamientos (llamados casos de uso) que son importantes para
los usuarios del sistema (llamados actores). Se crean distintos
escenarios para cada conjunto diferente de condiciones de un
caso de uso.
Los principales componentes del UML son cosas, relacio-
nes y diagramas. Los diagramas están relacionados entre sí. Las
cosas estructurales son más comunes; incluyen clases, interfa-
ces, casos de uso y muchos otros elementos que proveen la forma
de crear modelos. Las cosas estructurales permiten al usuario
describir relaciones. Las cosas de comportamiento describen la
forma en que trabajan las cosas. Las cosas de agrupamiento se
utilizan para definir límites. Las cosas de anotaciones permiten
al analista agregar notas a los diagramas.
Las relaciones son el pegamento que mantiene todo unido.
Las relaciones estructurales se utilizan para enlazar las cosas en
los diagramas estructurales. Las relaciones estructurales inclu-
yen dependencias, agregaciones, asociaciones y generalizacio-
nes. Los diagramas de comportamiento utilizan los cuatro tipos
básicos de relaciones de comportamiento: comunica, incluye,
extiende y generaliza.
El conjunto de herramientas de UML está compuesto de
diagramas de UML. Aquí se incluyen los diagramas de casos de uso,
diagramas de actividad, diagramas de secuencia, diagramas de
comunicación, diagramas de clases y diagramas de estados.
Además de los diagramas, los analistas pueden describir un caso
de uso mediante un escenario de casos de uso.
Mediante el uso de UML de manera iterativa en el análisis
y el diseño podemos lograr una mejor comprensión entre el
equipo de negocios y el equipo de TI en relación con los reque-
rimientos del sistema y los procesos que necesitan ocurrir en el
sistema para cumplir con esos requerimientos.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 317
E X P E R I E N C I A D E H Y P E R C A S E ® 1 0
“Espero que aún se sienta como si estuviera aprendiendo nue-
vas cosas sobre MRE. Entiendo que ha estado hablando con algunas
de las personas de sistemas: Melissa, Todd, Roger (e incluso con
Lewis, nuestro nuevo interno) acerca de usar algunos métodos dis-
tintos para crear diagramas y comprendernos mejor. Espero que nos
vea como una familia y no sólo como una colección de personas.
Sin duda todos nos sentimos como si hubiéramos ‘heredado’ una
gran sabiduría de Jimmy Hyatt y del padre de Warren. Estoy com-
pletamente de acuerdo en usar su nueva metodología, si nos ayuda
a mejorar los informes de nuestros proyectos. Desde luego que
Snowden está ansioso de ver su trabajo orientado a objetos. ¿Podría
presentarle algo en su escritorio en un par de semanas?”.
Preguntas de HYPERCASE
1. Cree un diagrama de actividad para el caso de uso Progreso
del proyecto de informes (Report Project Progress). Consulte
las especificaciones del caso de uso en la oficina de Melissa
Smith para ver los detalles y un prototipo.
2. Cree un diagrama de actividad para el caso de uso Agregar
cliente (Add Client). Consulte las especificaciones del caso
de uso en la oficina de Melissa Smith para ver los detalles y
un prototipo que encontrará en la oficina de Todd Taylor.
3. Cree un diagrama de secuencia para la ruta principal del caso
de uso Progreso del proyecto de informes. Consulte las
especificaciones del caso de uso en la oficina de Melissa
Smith para ver los detalles y un prototipo.
4. Cree un diagrama de secuencia para la ruta principal del caso
de uso Agregar cliente. Consulte las especificaciones del
caso de uso en la oficina de Melissa Smith para ver los detalles
y un prototipo que encontrará en la oficina de Todd Taylor.
5. Cree un diagrama de estados para la clase Asignación
(Assignment). Se crean asignaciones para las tareas, se
seleccionan los recursos, se actualizan las horas y se
terminan las asignaciones.
6. Cree un diagrama de estados para la clase Tarea (Task). Las
tareas se crean, pero no se inician; se planean, algunas veces
se retienen, se trabaja en ellas actualmente y se completan.
FIGURA 10.HC1
Encontrará los diagramas de
secuencia en HyperCase.
PALABRAS CLAVE Y FRASES
actor
agregación
Ajax
asociación
barra de sincronización
bifurcación
carril
caso de uso primario
clase
clase abstracta
clase de control
clase de entidad
clase de límite
colaboraciónwww.xlibros.com

318 PARTE III • EL PROCESO DE ANÁLISIS
cosa de anotación
dependencias
diagrama de actividad
diagrama de casos de uso
diagrama de clases
diagrama de comunicación
diagrama de despliegue
diagrama de estados
diagrama de secuencia
escenario de casos de uso
estado
estructura todo/parte
evento
evento temporal
fusión
generalización/especialización (gen/spec)
herencia
lenguaje unificado de modelado (UML)
mensaje
mensaje asíncrono
mensaje sincrónico
objeto
orientado a objetos
paquete
polimorfismo
proceso unificado
ramificación
redefinición de métodos
relación
ruta principal
sobrecarga de métodos
tarjetas CRC
unir
PREGUNTAS DE REPASO
1. Liste dos razones de utilizar una metodología orientada a objetos para el desarrollo de sistemas.
2. Describa la diferencia entre una clase y un objeto.
3. Explique el concepto de herencia en los sistemas orientados a objetos.
4. ¿Qué significa CRC?
5. Describa lo que agrega el Pensamiento en objetos a la tarjeta CRC.
6. ¿Qué es UML?
7. ¿Cuáles son los tres elementos principales del UML?
8. Haga una lista de lo que incluye el concepto de cosas estructurales.
9. Haga una lista de lo que incluye el concepto de cosas de comportamiento.
10. ¿Cuáles son los dos tipos principales de diagramas en UML?
11. Haga una lista de los diagramas que se incluyen en los diagramas estructurales.
12. Haga una lista de los diagramas que se incluyen en los diagramas de comportamiento.
13. ¿Qué es lo que describe un modelo de casos de uso?
14. ¿Describiría un modelo de casos de uso como un modelo lógico o físico del sistema? Defienda su respuesta en un
párrafo.
15. Defina qué es un actor en un diagrama de casos de uso.
16. ¿Cuáles son las tres cosas que un caso de uso siempre debe describir?
17. ¿Qué es lo que describe un diagrama de actividad?
18. Escriba un párrafo que describa el uso de los carriles en los diagramas de actividad.
19. ¿Qué se puede describir en un diagrama de secuencia o de comunicación?
20. ¿Por qué definir clases es una tarea tan importante del análisis orientado a objetos?
21. ¿Qué se puede mostrar en un diagrama de clases?
22. Defina la sobrecarga de métodos.
23. Mencione las cuatro categorías en las que se clasifican las clases.
24. ¿Cuáles son los pasos para crear un diagrama de secuencia?
25. ¿Cuáles son las dos categorías de relaciones entre clases?
26. ¿Para qué se utilizan los diagramas de generalización/especialización (gen/spec)?
27. ¿Cuál es otro término para el polimorfismo?
28. ¿Qué se describe mediante un diagrama de estados?
29. ¿Qué es un paquete en la metodología del UML?
30. ¿Por qué es importante usar el UML para el modelado?
PROBLEMAS
1. Cree una serie de tarjetas CRC para la División de catálogos de World’s Trend. Una vez colocado un pedido, el equipo
de abastecimiento de pedidos se hace cargo y revisa la disponibilidad, abastece el pedido y calcula el monto total del
mismo. Use cinco tarjetas CRC, una para cada una de las siguientes clases: pedido, abastecimiento de pedido, inventario,
producto y cliente. Complete la sección sobre clases, responsabilidades y colaboradores.
2. Termine las tarjetas CRC del problema 1; cree enunciados de Pensamiento en objetos y nombres de propiedades para
cada una de las cinco clases.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 319
3. Dibuje un diagrama de casos de uso para la División de catálogos de World’s Trend.
4. Dibuje cuatro imágenes que muestren ejemplos de cuatro tipos de relaciones de comportamiento para la agencia
automotriz BMW de Joel Porter. ¿Qué tipo de relación hay implicada cuando un cliente debe hacer arreglos de
financiamiento? ¿Hay actividades comunes involucradas cuando una persona arrenda o compra un automóvil? ¿Qué tipo
de relación existe entre un empleado que es un gerente o uno que es un vendedor?
5. Dibuje un diagrama de comunicación para un estudiante que toma un curso de un maestro que forma parte del cuerpo
docente.
6. El condado Coleman tiene una central telefónica que se hace cargo de las llamadas entre los que llaman y los que
reciben la llamada. Dados estos tres actores, dibuje un diagrama de secuencia simple para realizar una simple llamada
telefónica.
7. Usted está listo para empezar el modelado de UML para la clínica Kirt. Dibuje un diagrama de clases que incluya a un
médico, un paciente, una cita y la factura de un paciente. No involucre a la compañía de seguros.
8. Use UML para dibujar ejemplos de las cuatro relaciones estructurales para la clínica Kint.
9. Escriba un escenario de caso de uso de ejemplo para un paciente que ve a un médico en la clínica Kint.
10. El Woody’s Supermarket, una pequeña cadena de tiendas de abarrotes, está construyendo un sitio Web para permitir a
los clientes realizar pedidos de abarrotes y otros artículos. El cliente coloca un pedido Web, se actualiza el archivo
maestro de clientes y se crea un registro de pedido. El pedido se imprime en una tienda local y los empleados de la
tienda recogen los artículos de los estantes. Los clientes reciben una notificación vía correo electrónico de que su pedido
está listo. Cuando recogen el pedido, se agregan los artículos congelados, productos helados y demás artículos
relacionados. Dibuje un diagrama de actividad que muestre cómo el cliente coloca su pedido mediante el sitio Web,
cómo se verifica el pedido, cómo se confirma, como se envían los detalles relacionados a la tienda local y cómo se envía
un mensaje de correo electrónico al cliente.
11. Sludge’s Auto (consulte el capítulo 12) es un centro de reciclaje de auto partes que utiliza Ajax en sus sitios Web para
que sus clientes naveguen en busca de partes. Ajax permite al sitio Web obtener datos del servidor mientras el usuario
permanece en la página Web original. El cliente necesita conocer la marca, modelo y año de un auto así como la pieza.
Si la pieza está en existencia, aparecen la descripción, condición de la pieza, precio y costo de envío, junto con la
cantidad disponible para cada condición de la pieza y una imagen de la misma. Dibuje un diagrama de secuencia que
utilice clases de límite, control y entidad para la Consulta de auto partes de Sludge’s Auto.
12. Musixscore.com es un servicio en línea que provee partituras musicales a sus clientes. En la página Web “explorar
música” los clientes seleccionan un género de música de una lista desplegable. La página Web utiliza Ajax para obtener
una lista de artistas, músicos o grupos que coincidan con el género, lo cual se muestra en un formato de lista
desplegable. Al hacer una selección de la lista desplegable del artista, la página Web utiliza Ajax para mostrar una
tercera lista desplegable con todos los CD o demás obras del artista. Cuando se selecciona un CD, la página Web utiliza
Ajax para obtener todas las canciones del CD en una cuarta lista desplegable. El espectador puede hacer selecciones
múltiples. Al hacer clic en la imagen Agregar al carrito de compras las canciones se agregan al carrito de compras. El
espectador puede cambiar cualquiera de las listas desplegables para seleccionar partituras musicales adicionales y se
repite el proceso.
a. Escriba una descripción para el caso de uso Explorar partitura musical que represente esta actividad.
b. Dibuje un diagrama de secuencia que utilice clases de límite, control y entidad para la página Web de Musixscore.
c. Escriba una lista de los mensajes, nombres y parámetros, junto con los tipos de datos que se pasarían a las clases y
los valores (con los tipos de datos) que se incluyen con el mensaje de retorno. Haga todas las suposiciones
necesarias sobre los datos.
d. Cree un diagrama de clases para las clases de entidad utilizadas en el diagrama de secuencia.
BIBLIOGRAFÍA SELECCIONADA
Beck, K. y W. Cunningham. “Laboratory for Teaching Object-Oriented Thinking”, OOPSLA’89, según lo citado en D. Butler,
CRC Card Session Tutorial. www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/tutorial.html. Último acceso en 29 de
julio de 2009.
Bellin, D. y S. Suchman Simone. The CRC Card Book. Indianápolis: Addison-Wesley Professional, 1997.
Booch, G., I. Jacobson y J. Rumbaugh. The Unified Modeling Language User Guide, 2ª. Edición. Indianápolis: Addison-
Wesley Professional, 2005.
Cockburn, A. Writing Effective Use Cases. Boston: Addison-Wesley Publishing Co., 2001.
Dobing, B. y J. Parsons. “How UML Is Used”. Communications of the ACM, Vol. 49, Núm. 5, mayo de 2006, pp. 109-113.
Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3ª. Edición. Indianápolis: Addison-
Wesley Professional, 2003.
Kulak, D. y E. Guiney. Use Cases: Requirements in Context, 2ª. Edición. Indianápolis: Addison-Wesley Professional, 2004.
Miles, R. y K. Hamilton. Learning UML 2.0. Indianápolis: O’Reilly Media, Inc., 2006.
Sahraoudi, A. E. K. y T. Blum. “Using Object-Oriented Methods in a System Lifecycle Process Model”. ACM SIGSOFT Soft-
ware Engineering Notes, Vol. 28, Núm. 2 (marzo de 2003).www.xlibros.com

320 PARTE III • EL PROCESO DE ANÁLISIS
E P I S O D I O 1 0
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Objetos con clase
“Los prototipos y diagramas que hemos creado realmente nos ayudaron a entender el proyecto”, sonríe Anna, mirando desde
su computadora. “Tengo una buena sensación sobre lo que estamos haciendo”.
“Igual yo”, contesta Chip. “Pero necesitamos trabajar en las páginas Web que serán utilizadas por un amplia variedad de
docentes y miembros del personal”.
“¿Por dónde quieres empezar?”, pregunta Anna. “¿Crees que deberíamos trabajar en el diagrama de clases?”.
Chip se reclina en su silla y piensa en voz alta. “No, necesitamos realizar otro modelado para determinar las clases, atri-
butos y métodos primero. Tenemos un diagrama E-R preliminar como punto inicial para las clases de entidad. Deberíamos
modelar el comportamiento de varios prototipos. Al examinar un prototipo, deberíamos hacer preguntas sobre cada campo. Si
la información se almacena en una tabla de base de datos, deberíamos obtenerla de alguna forma”.
“Sí, por lo general la incluiríamos en una lista desplegable”, reflexiona Anna.
“Bueno, no necesariamente”, responde Chip. “Si hay demasiadas entradas o si una lista depende de una acción
previa, deberíamos usar Ajax para recuperar la información y actualizar la página Web, creando listas desplegables o
vínculos”.
“Los programas de creación para agregar nueva información serán los que requieran más tecleo, pero los programas para
cambiar, eliminar y consultar dependen de los datos almacenados”, agrega Anna. “¿Por dónde deberíamos empezar?”.
“He estado pensando mucho en el prototipo que creamos para usar la Web para actualizar la imagen de todo el software
que se almacena en una máquina del laboratorio de computación”, dice Chip, inclinándose hacia delante en su silla. “Y con sala
de laboratorio me refiero a cualquier salón de clases o laboratorio que tenga el mismo conjunto de software en cada computa-
dora. La imagen de software se utiliza para refrescar las computadoras dañadas o para reemplazar el software en una máquina
infectada por un virus o cualquier otro problema”.
“Bueno, demos un vistazo a ese prototipo ACTUALIZAR IMAGEN DE LABORATORIO”, dice Anna.
Chip muestra el prototipo (consulte el caso de la CPU del capítulo 6). “Necesitamos conocer el número de cuarto y de
campus para buscar la imagen de software”, dice Chip mientras apunta al primer par de campos en la página Web. “Estos nú-
meros se almacenan en tablas de la base de datos”.
“Sí, pero se almacenan con el software de programación administrativa en la mainframe”, interviene Anna. “Podríamos
copiarlos a los servidores Web, pero si cambian los edificios o los cuartos tendremos datos inconsistentes y un sistema poco
fiable”.
“Ahh, veo lo que quieres decir”, dice Chip. “¡Bien pensado! Tenemos que obtener estos datos de la mainframe”.
“Esto requiere el diagrama de actividad ACTUALIZAR IMAGEN DE LABORATORIO (que se muestra en la figura
E10.1)”, comenta Anna. “¿Por qué no creo el diagrama y tu revisas que esté correcto?”.
“Suena bien”, comenta Chip.
Anna empieza a dibujar el diagrama. “Como sólo ciertos miembros del personal tendrán la autorización para actualizar la
imagen del laboratorio, creo que debería empezar con ellos iniciando sesión en el sistema. Si es un inicio de sesión válido, se
enviará una solicitud al estado de la mainframe llamada OBTENER SALAS EDIFICIO CAMPUS para obtener los edificios
del campus y las salas dentro de éstos. Esta lista se envía de vuelta al programa ENVIAR LISTA EDIFICIO CAMPUS en el
servidor Web, en donde se convierte en un documento de XML y se envía a la página Web SELECCIONAR EDIFICIO DE
CAMPUS”.
Chip pregunta: “¿Vas a poner todas las salas en la lista para todos los edificios? Eso sería un extenso documento de XML
y podría tardar un tiempo en cargarse en el navegador”.
“ La otra opción sería incluir sólo los edificios y después solicitar las salas para un edificio de campus seleccionado”,
responde Anna pensativamente. “Eso también sería aceptable, pero alentaría el proceso de seleccionar salas ya que el navegador
tendría que esperar que las salas se actualizaran en la lista desplegable. Si se enviara todo el documento de XML a la vez, la
lista de salas se actualizaría rápidamente a partir de los elementos del documento a nivel del navegador. Sería muy rápido. Así
el usuario seleccionaría un edificio del campus y sólo aparecerían las salas para ese edificio”.
“Tengo una idea”, exclama Chip. “Cuando el programa obtiene las salas de los edificios, ¿hay alguna forma de seleccionar
sólo las salas que son laboratorios de computadoras?”.
“Es una excelente idea”, dice Anna. “El documento de XML sería más pequeño y se cargaría más rápido en el navegador.
Tal vez tengamos que solicitar una modificación de la tabla de la base de datos para tener un código para los laboratorios de
computadora”.
“Voy a ver eso”, responde Chip. “Entonces, ¿qué ocurre después de que obtenemos una sala de laboratorio?”.
Anna piensa por un momento, “Necesitamos una tabla de imágenes del laboratorio en el servidor Web que contenga el
número de sala y el software incluido en ella. Esto incluye el software estándar, como el sistema operativo, procesamiento de
palabras y software para escanear virus, ya que pueden cambiar de una sala a otra. Agregaré un estado para OBTENER SOFT-
WARE DE COMPUTADORA PARA SALA en el carril Servidor Web”.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 321
Sistema de
inicio de sesión
Validar inicio
de sesión
Seleccionar edificio
del campus
Seleccionar lista de
edificios del campus
Obtener software de
computadora para
la sala
Obtener sala de software
de computadora
Buscar software
que coincida
Seleccionar sala
Seleccionar
nuevo software
Actualizar lista
de software
Actualizar imágenes
de software del
laboratorio
Solicitar cambios
en la imagen
Acción de página Web
Agregar software a imagen
No más nuevo software
Sin cambios
Más software
Página Web cliente Servidor Web Mainframe
No hay nuevo software
Se transmitió formulario
Error de inicio de sesión inválido
Valores XML de salas
de edificios
Edificio y sala seleccionados
Lista de software
Se enviaron las primeras
3 letras del software
No se encontró software que coincida
Se encontró software que coincide
Cambios de software
Actualización exitosa
Obtener salas de edificios del campus
Salas de edificios
FIGURA E10.1
Diagrama de actividad ACTUALIZAR
IMAGEN DE LABORATORIO
Chip pregunta: “¿Incluimos una lista desplegable para el software?”.
“No, eso dificultaría quitar el software o cambiar la versión”, responde Anna pensativamente. “Creo que deberíamos mos-
trar el software en una lista en la página Web y permitirles actualizar el número de versión”.
“El problema es que tal vez tengamos una lista extensa de software y haya que eliminar parte del software también!”,
comenta Chip. “¿Por qué no usamos un modelo de correo electrónico, con una casilla de verificación en frente de cada título de
software y limitamos el número de títulos de software por página? Podríamos incluir un botón de siguiente página para mostrar
el siguiente grupo de títulos de software”.
“¿Cómo sabe el programa de eliminación qué paquete de software eliminar?”, pregunta Anna.
“Necesitamos incluir el número de software como campo oculto que se transmita al servidor Web”, responde Chip. “¿Qué
piensas sobre agregar software a la imagen del laboratorio?”.
Anna piensa por unos minutos. “¿Por qué no usamos Ajax de nuevo para hacer que introduzcan las primeras letras del título
de software en un campo de texto de entrada? Podríamos enviar la solicitud a la tabla Software en el servidor Web y devolverwww.xlibros.com

322 PARTE III • EL PROCESO DE ANÁLISIS
una lista de los títulos que coincidan. La página Web crearía un bloque rectangular flotante en la parte superior de la página Web
con una lista de los vínculos a los títulos de software y los campos ocultos almacenados con el vínculo. El usuario haría clic en
un título para agregarlo a la imagen. Después podría agregar otro título de software si fuera necesario. Ésta es la actividad SE-
LECCIONAR NUEVO SOFTWARE que envía las primeras tres letras al estado BUSCAR SOFTWARE QUE COINCIDA del
servidor Web. ACTUALIZAR LISTA DE SOFTWARE crea el bloque flotante de títulos”.
“¡Excelente idea!”, exclama Chip.
“Al terminar de agregar software, revisar el software que se va a quitar y cambiar los números de las versiones, hacen clic
en el botón enviar y la tabla de la base de datos de imágenes del laboratorio se actualiza con los cambios”, dice Anna. “El
estado SOLICITAR CAMBIOS EN IMAGEN envía los cambios al estado ACTUALIZAR IMAGEN SOFTWARE LABORA-
TORIO”.
“Esto es divertido”, sonríe Chip. “Voy a trabajar en un diagrama de secuencia para el prototipo ACTUALIZAR IMAGEN
LABORATORIO (que se muestra en la figura E10.2). Chip empieza por enviar la solicitud para la página Web Actualizar la-
boratorio. El servidor envía el mensaje obtenerCampus() a la clase CAMPUS, la cual devuelve la listaCampus incluyendo un
codigoCampus y una descripcionCampus. El controlador envía un mensaje a la clase SALA DE CAMPUS para obtener salas
que contengan software de laboratorio, las cuales se devuelven al CONTROLADOR ACTUALIZAR IMAGEN LABORATO-
RIO COMPUTADORAS. La clase controladora crea el documento de XML listaSalas y lo envía al navegador Web, el cual crea
la lista de selección Edificio de campus. Al cambiar la lista de Edificios del campus, el navegador Web utiliza el mismo docu-
mento de XML para cambiar la lista desplegable Número de sala, de manera que sólo incluya las salas de laboratorio en el
edificio del campus seleccionado.
Cuando se modifica la lista desplegable Número de sala, se envía una solicitud obtenerSoftwareSala() a la clase controla-
dora, que a su vez envía un mensaje obtenerSoftwareImagen() a la clase IMAGEN SOFTWARE. Mediante el uso del número
de sala se obtiene el software y se devuelve en la listaSoftware. LA clase controladora utiliza la listaSoftware para crear el XML
que se envía a la clase de interfaz ACTUALIZAR IMAGEN LABORATORIO COMPUTADORAS, que actualiza la página
Web con los títulos de software.
Cuando se introduce un título parcial de software, se envía una solicitud seleccionarSoftware() al CONTROLADOR
ACTUALIZAR IMAGEN LABORATORIO COMPUTADORAS, el cual envía un mensaje buscarSoftware() a la clase de
:Actualizar
imagen
laboratorio
computadoras
:Campus :Sala de
campus
:Imagen de
software :Software
cargar Página Web
actualizar laboratorio
Página Web actualizar
software laboratorio
cambiar Lista campus
enviarURLPaginaWeb
enviar Página imagen
laboratorio
obtenerSalaCampus()
obtenercampus()
regresar listaCampus
regresar listaSalas
regresar listaSoftware
regresar éxito
return softwareList
buscarSoftware()
obtenerSala()
obtenerSoftwareSala() obtenerSoftwareImagen()
actualizarImagenSala()
actualizar listaSalas
actualizar lista de
software
seleccionarSoftware()
regresar titulos-
Coincidencias
actualizar imagen()
Enviar confirmación
cambiar Lista de salas
mostrar software de
laboratorio
mostrar Nuevo software
Enviar solicitud de
imagen
Introducir Título
parcial de software
Lista de salas
disponible
:Controlador
actualizar imagen
laboratorio
computadoras
Docente
FIGURA E10.2
Diagrama de secuencia ACTUALIZAR
IMAGEN DE LABORATORIO.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 323
Software
Recibido
Software
Desplazado
Software
Instalado
Software
Actualizado
Software
Eliminado
se instaló el software
en las máquinas
se actualizó el software
se desplazó el software
a un nuevo equipo se actualizó
el software
software
sin utilizar
se recibió software
FIGURA E10.3
Diagrama de estados
SOFTWARE.
entidad SOFTWARE. Se busca el software que coincida y se envía la listaSoftware que contiene el número de software,
descripción y versión a la clase controladora. Esto da formato al documento de XML, que se envía a la clase de interfaz
ACTUALIZAR IMAGEN LABORATORIO COMPUTADORAS. El navegador Web da formato al bloque flotante de títu-
los de software. Al seleccionar un título, el navegador lo agrega a la lista de títulos de software y se quita el bloque flo-
tante.
Al hacer clic en el botón Enviar solicitud de imagen en la página Web, se envía la solicitud actualizarImagen() al contro-
lador, el cual envía un mensaje actualizarImagenSala() a la clase de entidad IMAGEN DE SOFTWARE. La tabla de la base de
datos se actualiza y se devuelve el mensaje de éxito al controlador, que a su vez envía una página Web de confirmación.
“El software parece un poco complicado, ya que se reemplazan distintas versiones y paquetes de software por otras dife-
rentes”, comenta Anna. “Creo que es buena idea dibujar un diagrama de estados para el software. Esto nos dará una idea de los
métodos y atributos de software, además de la interfaz que necesitaremos para cambiar esos atributos”.
Anna empieza a trabajar en un diagrama de estados SOFTWARE. Al recibir por primera vez el software, se introduce en
el sistema mediante el formulario AGREGAR SOFTWARE de Microsoft Access y se cambian los valores de los atributos
iniciales. Hay que agregar todo el software antes de poder instalarlo en las máquinas, por lo que se difiere el evento SOFTWARE
INSTALADO EN LAS MÁQUINAS hasta que se haya agregado.
Una vez instalado el software en cualquier cantidad de máquinas, existe en el estado SOFTWARE INSTALADO durante
mucho tiempo. Se actualiza la tabla relacional HARDWARE-SOFTWARE para reflejar el estado actual. De vez en cuando se
reemplaza una máquina y el software se mueve a una máquina distinta. Se vuelve a actualizar la tabla HARDWARE-SOFT-
WARE para reflejar la nueva ubicación. Cuando hay una nueva versión del software disponible, se actualiza con un formulario
CAMBIAR SOFTWARE de Microsoft Access. O también se puede eliminar el software del sistema mediante el formulario ELI-
MINAR SOFTWARE de Microsoft Access. En la figura E10.3 se muestra el diagrama de estados SOFTWARE completo.
Chip y Anna trabajan en varios diagramas de actividad, secuencia y estados. Después de haber completado varios diagra-
mas, Chip comenta: “Creo que tenemos suficiente información para crear un diagrama de clases”.
Anna concuerda, “Sí, vamos a asignar las relaciones”.
En la figura 10.4 se muestra el diagrama de clases SISTEMA COMPUTARIZADO. Cada clase tiene atributos privados y
métodos públicos en Microsoft Access para actualizar los atributos. Las principales clases son Computadora y Software, con
una clase asociativa HardwareSoftware que las conecta. Esta clase se utiliza para implementar la relación de muchos a muchos
entre el hardware y el software. Cada paquete de software pertenece a una Categoría de software y también tiene un Experto de
software a quien se puede llamar para obtener soporte. Cada computadora tiene uno o más sistemas operativos y se localiza en
un edificio del campus.www.xlibros.com

324 PARTE III • EL PROCESO DE ANÁLISIS
Ejercicios
E-1. Use Microsoft Visio o Visible Analyst para ver el diagrama de actividad ACTUALIZAR IMAGEN LABORATORIO
(UPDATE LAB IMAGE).
E-2. Use Microsoft Visio o Visible Analyst para ver el diagrama de secuencia ACTUALIZAR IMAGEN LABORATORIO
(UPDATE LAB IMAGE).
E-3. Use Microsoft Visio o Visible Analyst para ver el diagrama de estados SOFTWARE.
E-4. Use Microsoft Visio o Visible Analyst para ver el diagrama de clases SISTEMA COMPUTARIZADO (COMPUTER
SYSTEM).
Computadora
–numeroInventarioHardware
–tipoComputadora
–nombreMarca
–modelo
–numeroSerie
–fechaCompra
–costoCompra
–costoReemplazo
–tamanioMemoria
–capacidadDiscoDuro
–capacidadSegundoDiscoDuro
–discoOptico
–garantia
–codigoCampus
–ubicacionSala
–numeroDistribuidor
+agregarComputadora()
+cambiarComputadora()
+eliminarComputadora()
+obtenerComputadora()
Software
–numeroInventarioSoftware
–titulo
–nombreSistemaOperativo
–numeroVersion
–editor
–codigoCategoriaSoftware
–marcaComputadora
–memoriaRequerida
–licenciaSitio
–numeroDeCopias
–costoSoftware
–numeroEmpleado
+agregarSoftware()
+cambiarSoftware()
+obtenerSoftware()
+obtenerTituloSoftware()
+eliminarSoftware()
Edificio Campus
–codigoCampus
–descripcionCampus
+agregarEdificio()
Experto Software
–numeroEmpleado
–apellidoPaterno
–primerNombre
–telefonoOficina
–email
–codigoDepartamento
–enseñaCurso
+agregarExperto()
+cambiarExperto()
+eliminarExperto()
+obtenerExperto()
HardwareSoftware
–numeroInventarioHardware
–numeroInventarioSoftware
+instalarSoftware()
+actualizarVersion()
+eliminarSoftware()
+obtenerSoftware()
+obtenerHardware()
Sistema Operativo
–codigoSistemaOperativo
–significadoSistemaOperativo
+agregarSistemaOperativo()
+cambiarSistemaOperativo()
+eliminarSistemaOperativo()
+obtenerSistemaOperativo()
Categoria Software
–codigoCategoriaSoftware
–descripcionCategoriaSoftware
+agregarNuevaCategoria()
+cambiarNombreCategoria()
+eliminarCategoria()
+obtenerCategoria()
1
1
1
11
FIGURA E10.4
Diagrama de clases SISTEMA COMPUTARIZADO.www.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 325
Los siguientes ejercicios se pueden realizar con Microsoft Visio o con Visible Analyst. Hay que usar un rectángulo para
un símbolo de clase al dibujar diagramas de secuencia con Microsoft Visio o Visible Analyst (los símbolos de estereotipo
de clase no están disponibles). Coloque una etiqueta de texto arriba de cada rectángulo para identificar el tipo de clase:
interfaz, control o entidad.
E-5. Modifique e imprima el diagrama de actividad REGISTRAR PARA CAPACITACIÓN (REGISTER FOR TRAINING).
Consulte la figura E12.3 en el Episodio del caso de la CPU del capítulo 12 para ver el prototipo de esta página Web.
Agregue los siguientes símbolos de estado y conexiones de eventos:
a. El estado CREAR DATOS XML EMPLEADO (CREATE XML EMPLOYEE DATA) en el carril SERVIDOR WEB
(WEB SERVER) debajo del estado OBTENER INFORMACIÓN EMPLEADO (GET EMPLOYEE INFORMA-
TION). Conéctelo con una flecha de evento que venga de LEER REGISTRO EMPLEADO (READ EMPLOYEE
RECORD). Asigne al evento la etiqueta ENVIAR DATOS EMPLEADO (SEND EMPLOYEE DATA).
b. Agregue el estado PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB PAGE) en
el carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE) a la izquierda del estado CREAR DATOS XML EM-
PLEADO (CREATE XML EMPLOYEE DATA). Conecte los dos estados con una flecha de evento hacia el estado
PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB PAGE) etiquetada como
ENVIAR DOCUMENTO XML EMPLEADO (SEND EMPLOYEE XML DOCUMENT).
c. Agregue un estado debajo del estado CREAR DATOS XML EMPLEADO (CREATE XML EMPLOYEE DATA)
que se llame BUSCAR CLASE CAPACITACIÓN SOFTWARE (FIND SOFTWARE TRAINING CLASS). Conéc-
telo con una flecha de evento que provenga del estado PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE
INFORMATION WEB PAGE) y etiquétela como NIVEL DE SOFTWARE Y CAPACITACIÓN SELECCIONADO
(SELECTED SOFTWARE AND TRAINING LEVEL).
d. Incluya un símbolo de diamante de decisión debajo del estado BUSCAR CLASE CAPACITACIÓN SOFTWARE
(FIND SOFTWARE TRAINING CLASS). Conéctelo con una flecha de evento que provenga del estado BUSCAR
CLASE CAPACITACIÓN SOFTWARE (FIND SOFTWARE TRAINING CLASS). Un evento debe fluir a la iz-
quierda hacia el estado PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB
PAGE), etiquetado como NO SE ENCONTRÓ LA CLASE (CLASS NOT FOUND).
e. Agregue un estado SELECCIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS) debajo del estado
PÁGINA WEB INFORMACIÓN EMPLEADO (EMPLOYEE INFORMATION WEB PAGE), y un tanto debajo del
diamante de decisión. Conecte la parte inferior del diamante de decisión con una flecha de evento que vaya hacia el
estado SELECCIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS). Etiquétela como CLASES CAPA-
CITACIÓN SOFTWARE (SOFTWARE TRAINING CLASES).
f. Agregue un estado debajo del diamante de decisión y un tanto debajo del estado SELECCIONAR CLASE SOFT-
WARE (CHOOSE SOFTWARE CLASS). Etiquételo como ACTUALIZAR PARTICIPANTE CLASE (UPDATE
CLASS PARTICIPANT).
g. Conecte el estado SELECCIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS) con una flecha de
evento que apunte al estado ACTUALIZAR PARTICIPANTE CLASE (UPDATE CLASS PARTICIPANT). Etiqué-
tela como ENVIAR SOLICITUD INSCRIBIR CLASE (SEND ENROLL CLASS REQUEST).
h. Agregue un símbolo de círculo de salida en la parte inferior del carril Página Web cliente. Conecte el estado SELEC-
CIONAR CLASE SOFTWARE (CHOOSE SOFTWARE CLASS) con una flecha de evento que apunte al círculo de
salida y etiquétela como CANCELAR (CANCEL).
i. Conecte el estado ACTUALIZAR PARTICIPANTE CLASE (UPDATE CLASS PARTICIPANT) con una flecha de
evento que apunte al círculo de salida y etiquétela como ACTUALIZACIÓN EXITOSA (SUCCESSFUL UPDATE).
E-6. Cree e imprima el diagrama de actividad CALENDARIO CAPACITACIÓN (TRAINING CALENDAR). El prototipo
para esta página Web se ilustra en la figura E11.4, que encontrará en el Episodio del caso de la CPU del capítulo 11.
Agregue un círculo de inicio en la esquina superior izquierda del diagrama y agregue los siguientes carriles, símbolos de
estado y conexiones de eventos:
a. Agregue un carril a la izquierda etiquetado como PÁGINA WEB CLIENTE (CLIENT WEB PAGE) y uno a la de-
recha llamado SERVIDOR WEB (WEB SERVER).
b. Agregue un círculo de inicio en la parte superior del carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE) y de-
bajo de éste un estado etiquetado como SOLICITAR PÁGINA WEB CALENDARIO CAPACITACIÓN (REQUEST
TRAINING CALENDAR WEB PAGE). Conecte el círculo de inicio al estado con una flecha de evento.
c. Agregue un estado en el carril SERVIDOR WEB, a la derecha del estado SOLICITAR PÁGINA WEB CALENDA-
RIO CAPACITACIÓN (REQUEST TRAINING CALENDAR WEB PAGE). Etiquételo como OBTENER CLASE
CAPACITACIÓN (GET TRAINING CLASS).
d. Conecte el estado izquierdo al derecho con una flecha de evento etiquetada como SE TRANSMITIÓ FORMULA-
RIO (FORM TRANSMITTED).
e. Coloque un estado debajo del estado OBTENER CLASE CAPACITACIÓN (GET TRAINING CLASS). Etiquételo
como OBTENER CLASE CAPACITACIÓN (GET TRAINING CLASS), Conecte los dos estados con una flecha de
evento hacia abajo etiquetada como ENVIAR NÚMERO CURSO (SEND COURSE NUMBER).
f. Coloque un estado en el carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE) a la izquierda del estado OBTE-
NER CLASE CAPACITACIÓN (GET TRAINING CLASS). Etiquételo como PANTALLA CURSO CALENDA-
RIO CAPACITACIÓN (TRAINING CALENDAR COURSE DISPLAY). Conecte los dos estados con una flecha de
evento que apunte hacia la izquierda y etiquétela como ENVIAR VALORES XML CLASE CAPACITACIÓN
(SEND TRAINING CLASS XML VALUES).www.xlibros.com

326 PARTE III • EL PROCESO DE ANÁLISIS
g. Coloque un círculo de salida en la parte inferior del carril PÁGINA WEB CLIENTE (CLIENT WEB PAGE). Conecte
el estado PANTALLA CURSO CALENDARIO CAPACITACIÓN (TRAINING CALENDAR COURSE DISPLAY)
con una flecha de evento que apunte a la derecha y arriba por el lado derecho del carril SERVIDOR WEB (WEB SER-
VER), hacia el estado PANTALLA CURSO CALENDARIO CAPACITACIÓN (TRAINING CALENDAR COURSE
DISPLAY). Etiquétela como CAMBIAR FECHA O CAMBIAR ORDEN (DATE CHANGE OR SORT CHANGE).
E-7. Modifique e imprima el diagrama de secuencia REGISTRARSE PARA CAPACITACIÓN (REGISTER FOR TRAI-
NING). Agregue dos nuevas clases de entidad del lado derecho del diagrama y extienda la línea de vida hacia abajo, hasta
la parte inferior del diagrama. Las clases son Empleado y Clase. Agregue los siguientes mensajes del CONTROLADOR
REGISTRARSE PARA CLASE (REGISTER FOR CLASS CONTROLLER) y agregue los rectángulos de foco de con-
trol en donde los mensajes interactúan con la línea de vida de la clase:
a. obtenerEmpleado() [getEmployee()] del controlador a EMPLEADO (EMPLOYEE).
b. regresar datosEmpleado (return employeeData) de la clase EMPLEADO (EMPLOYEE) al controlador.
c. buscarClaseSoftware() [findSoftwareClass()] del controlador a la clase de entidad CLASE (CLASS).
d. regresar listaClaseSoftware (return softwareClassList) de la clase de entidad CLASE (CLASS) al controlador.
e. actualizarParticipanteClase() [updateClassParticipant()] del controlador a la clase de entidad CLASE (CLASS).
f. regresar éxito (return success) de la clase de entidad CLASS al controlador.
E-8. Cree e imprima el diagrama de secuencia CALENDARIO CAPACITACIÓN (TRAINING CALENDAR). Agregue el
actor Docente (Faculty) en la esquina superior izquierda del diagrama y después las siguientes clases, de izquierda a
derecha, a lo largo de la parte superior del diagrama:
a. La clase de interfaz Mostrar clases capacitación (Display Training Classes).
b. La clase de control Mostrar clases capacitación (Display Training Classes).
c. La clase de entidad Clase (Class).
d. La clase de entidad Curso (Course).
Agregue los siguientes mensajes entre las clases o entre el actor y la clase:
a. Cargar página Web Calendario capacitación (Load Training Calendar Web page) de Docente (Faculty) a la clase de
interfaz Mostrar clases capacitación (Display Training Classes).
b. enviarURLPaginaWeb (sendWebPageURL) de Mostrar clases capacitación (Display Training Classes) a Controlador
Mostrar clases capacitación (Display Training Classes Controller).
c. obtenerClase() [getClass()] del controlador a la clase de entidad Clase (Class).
d. regresar listaClases (return classList) de la clase de entidad Clase (Class) al controlador.
e. obtenerDescripcionCurso() [getCourseDescription()] del controlador a la clase de entidad Curso (Course).
f. regresar descripcionCurso (return courseDescription) de la clase de entidad Curso (Course) al controlador.
g. actualizar listaCursos (update courseList) de la clase controladora a la clase de interfaz Mostrar clases capacitación
(Display Training Classes).
h. Página Web Software laboratorio (Lab Software Web Page) de la clase interfaz Mostrar clases capacitación (Display
Training Classes) al actor.
i. Cambiar mes/año (Change Month/Year) del actor a la clase de interfaz Mostrar clases capacitación (Display Training
Classes).
j. Una auto-transición en la clase de interfaz Mostrar clases capacitación (Display Training Classes) (use JavaScript para
actualizar el calendario).
k. Nuevo Calendario (New Calendar) de la clase de interfaz Mostrar clases capacitación (Display Training Classes) al actor.
l. Cambiar fecha (Change Date) del actor a la clase de interfaz Mostrar clases capacitación (Display Training Classes).
m. obtenerNuevaClase() [getNewClass()] de Mostrar clases capacitación (Display Training Classes) al controlador.
n. Repita los pasos c a g.
o. Lista cursos disponible (Course List Available) de la clase de interfaz Mostrar clases capacitación (Display Training
Classes) al actor.
E-9. Modifique e imprima el diagrama de estados Capacitación (Training). Agregue dos estados después de CLASE CAPA-
CITACIÓN CANCELADA (CANCELLED TRAINING CLASS) del lado izquierdo del diagrama. Éstos son CLASE
CAPACITACIÓN ACTIVA (ACTIVE TRAINING CLASS) y, debajo de éste, CLASE CAPACITACIÓN COMPLE-
TADA (COMPLETED TRAINING CLASS). Agregue una clase debajo de CLASE CAPACITACIÓN PROGRAMADA
(SCHEDULED TRAINING CLASS) llamada INSCRITO CLASE CAPACITACIÓN (ENROLLED TRAINING
CLASS). Agregue las siguientes transiciones:
a. SE INSCRIBIERON PARTICIPANTES (PARTICIPANTS ENROLLED) del estado CLASE CAPACITACIÓN
PROGRAMADA (SCHEDULED TRAINING CLASS) al estado INSCRITO CLASE CAPACITACIÓN (ENRO-
LLED TRAINING CLASS).
b. CLASE EN SESIÓN (IN SESSION CLASS) del estado INSCRITO CLASE CAPACITACIÓN (ENROLLED TRA-
INING CLASS) al estado CLASE CAPACITACIÓN ACTIVA (ACTIVE TRAINING CLASS).
c. FINALIZÓ SESIÓN CAPACITACIÓN (TRAINING SESSION ENDED) del estado CLASE CAPACITACIÓN
ACTIVA (ACTIVE TRAINING CLASS) al estado CLASE CAPACITACIÓN COMPLETADA (COMPLETED
TRAINING CLASS).
d. Una flecha de finalización del estado CLASE CAPACITACIÓN COMPLETADA (COMPLETED TRAINING
CLASS) a un área en blanco a la derecha.
E-10. Cree e imprima el diagrama de estados COMPUTADORA. Hay dos columnas de estados. En la columna izquierda in-
cluya los siguientes estados de arriba hacia abajo: NUEVA COMPUTADORA (NEW COMPUTER), CLEANING
COMPUTER (LIMPIANDO COMPUTADORA) y RECYCLED COMPUTER (COMPUTADORA RECICLADA). Enwww.xlibros.com

CAPÍTULO 10 • ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML 327
la columna derecha incluya los siguientes estados de arriba hacia abajo: COMPUTADORA INSTALADA (INSTALLED
COMPUTER), COMPUTADORA FUNCIONAL (FUNCTIONAL COMPUTER) y COMPUTADORA RETENIDA
REPARACIÓN (REPAIR HELD COMPUTER). Agregue las siguientes transiciones:
a. Empiece con SE RECIBIÓ COMPUTADORA (COMPUTER RECEIVED) que pase de un punto en el espacio arriba
del rectángulo de estado hacia el estado NUEVA COMPUTADORA (NEW COMPUTER).
b. COMPUTADORA INSTALADA (INSTALLED COMPUTER) del estado NUEVA COMPUTADORA (NEW
COMPUTER) al estado COMPUTADORA INSTALADA (INSTALLED COMPUTER).
c. SE INSTALÓ SOFTWARE (SOFTWARE INSTALLED) del estado COMPUTADORA INSTALADA (INSTA-
LLED COMPUTER) al estado COMPUTADORA FUNCIONAL (FUNCTIONAL COMPUTER).
d. SE PROGRAMÓ MANTENIMIENTO (MAINTENANCE SCHEDULED) del estado COMPUTADORA FUNCIO-
NAL (FUNCTIONAL COMPUTER) al estado LIMPIANDO COMPUTADORA (CLEANING COMPUTER).
e. SE COMPLETÓ MANTENIMIENTO del estado LIMPIANDO COMPUTADORA (CLEANING COMPUTER) al
estado COMPUTADORA FUNCIONAL (FUNCTIONAL COMPUTER).
f. SE REPORTÓ PROBLEMA (PROBLEM REPORTED) del estado COMPUTADORA FUNCIONAL (FUNCTIO-
NAL COMPUTER) al estado COMPUTADORA RETENIDA EN REPARACIÓN (REPAIR HELD COMPUTER).
g. SE COMPLETÓ REPARACIÓN (REPAIR COMPLETED) del estado COMPUTADORA RETENIDA EN REPARA-
CIÓN (REPAIR HELD COMPUTER) al estado COMPUTADORA RECICLADA (RECYCLED COMPUTER).
h. ACTUALIZAR COMPUTADORA IDENTIFICADA del estado COMPUTADORA FUNCIONAL (FUNCTIO-
NAL COMPUTER) al estado COMPUTADORA RECICLADA (RECYCLED COMPUTER).
i. SE IDENTIFICÓ REPARACIÓN IRREALIZABLE del estado COMPUTADORA RETENIDA EN REPARACIÓN
(REPAIR HELD COMPUTER) al estado COMPUTADORA RECICLADA (RECYCLED COMPUTER).
j. Una flecha de finalización del estado COMPUTADORA RECICLADA (RECYCLED COMPUTER) a un área en
blanco debajo del estado.
E-11. Modifique e imprima el diagrama de clase COMPUTADORA (COMPUTER). Cada computadora puede tener uno o más
sistemas operativos instalados. Mueva la clase Sistema operativo (Operating System) a la derecha de su ubicación actual
y agregue una nueva clase llamada Sistema operativo de computadora (Computer Operating System) debajo de la clase
Computadora (Computer). Cambie la línea conectora de Computadora a Sistema operativo para conectar la clase Sistema
operativo a la clase Sistema operativo de computadora. Agregue una nueva relación entre la clase Computadora (el lado
de uno) a la clase Sistema operativo de computadora (el lado de muchos). Agregue los siguientes atributos a la clase
Sistema operativo de computadora:
NumeroInventarioHardware
codigoSistemaOperativo
Agregue los siguientes métodos a la clase Sistema operativo de computadora:
agregarSistemaOperativoComputadora()
eliminarSistemaOperativoComputadora()
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de muestra de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access
que pueden usar para completar los ejercicios.www.xlibros.com

www.xlibros.com

329
C A P Í T U L O 1 1
Diseño de una salida efectiva
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender los objetivos para un diseño efectivo de la salida.
2. Relacionar el contenido de la salida con los métodos de salida, dentro y fuera de la
organización.
3. Comprender cómo afecta a los usuarios la predisposición en la salida.
4. Diseñar la salida de pantalla.
5. Diseñar tableros de control, widgets y gadgets.
6. Diseñar un sitio Web para comercio electrónico.
La salida es información que se entrega a los usuarios por medio del sis-
tema de información a través de intranets, extranets o la World Wide Web.
Algunos datos requieren de mucho procesamiento para poder convertirse
en una salida adecuada; otros se almacenan y, cuando se recuperan, se con-
sideran salida sin que necesiten mucho procesamiento (a veces no requie-
ren procesamiento en absoluto). La salida puede tomar muchas formas: la tradicional copia en
papel de los informes impresos y la copia transitoria como las pantallas, microformas y la salida
de video y audio. Los usuarios se basan en la salida para realizar sus tareas y con frecuencia
juzgan el mérito del sistema únicamente con base en ella. Para crear la salida más útil posible,
el analista de sistemas trabaja de cerca con el usuario a través de un proceso interactivo hasta
que se considere que el resultado es satisfactorio.
OBJETIVOS DE DISEÑO DE LA SALIDA
Como es esencial una salida útil para asegurar el uso y la aceptación del sistema de informa-
ción, hay seis objetivos que el analista de sistemas trata de alcanzar al diseñar la salida:
1. Diseñar la salida para servir al propósito previsto.
2. Diseñar la salida para ajustarla al usuario.
3. Entregar la cantidad apropiada de salida.
4. Asegurarse que la salida esté donde se necesite.
5. Proveer la salida en forma oportuna.
6. Elegir el método de salida correcto.
Diseñar la salida para servir al propósito previsto
Toda salida debe tener un propósito. Durante la fase de determinación de los requerimientos
de información del análisis, el analista de sistemas averigua qué propósitos de los usuarios y la
organización existen. Después se diseña la salida con base en esos propósitos.
P A R T E I V
Los fundamentos
del diseñowww.xlibros.com

330 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Usted tendrá numerosas oportunidades para proveer la salida simplemente porque la aplicación así se lo per-
mite. Sin embargo, recuerde la regla de propósito: si la salida no es funcional, no se debe crear ya que acarrea
costos de tiempo y materiales.
Diseñar la salida para ajustarla al usuario
En un sistema de información extenso que atiende a muchos usuarios con muchos fines, y a menudo es difí-
cil personalizar la salida. Con base en las entrevistas, observaciones, consideraciones de costo y tal vez los
prototipos, es posible diseñar una salida para atender lo que muchos usuarios (si no es que todos) necesitan y
prefieren.
Hablando en general, es más práctico crear una salida específica o personalizada para el usuario cuando se
diseña para un sistema de soporte de decisiones u otras aplicaciones con alto grado de interactividad, como las
que utilizan a la Web como plataforma. Sin embargo, sí es posible diseñar la salida para ajustarse a las tareas y la
función de un usuario en la organización, lo cual nos lleva al siguiente objetivo.
Entregar la cantidad apropiada de salida
Parte de la tarea de diseñar la salida es decidir qué cantidad de salida es la correcta para los usuarios. Una heurís-
tica útil es que el sistema debe proveer lo que necesita cada persona para realizar su trabajo. Pero esta respuesta
está aún lejos de ser una solución total, ya que tal vez sea apropiado mostrar un subconjunto de esa información
al principio y después ofrecer al usuario la manera de acceder a la información adicional con facilidad.
El problema de la sobrecarga de información se ha convertido en una condición muy frecuente, por lo que
constituye una preocupación para el diseñador de sistemas. No sirve de nada proporcionar información exce-
siva sólo para alardear sobre las capacidades del sistema. Siempre hay que tener en cuenta a los encargados de
tomar las decisiones. Muy raras veces necesitarán grandes cantidades de salida, en especial si hay una forma
sencilla de acceder a más información a través de un hipervínculo o una herramienta para explorar estructuras
jerárquicas.
Asegurarse que la salida esté donde se necesite
Con frecuencia la salida se produce en una ubicación y después se distribuye al usuario. El aumento en el uso de
la salida que se muestra a través de una pantalla en línea y a la que se puede acceder personalmente ha reducido
en parte el problema de la distribución, pero la distribución apropiada sigue siendo un objetivo importante para el
analista de sistemas. Para ser útil, la salida se debe presentar al usuario correcto. Sin importar qué tan bien dise-
ñados estén los informes, si no los ven los encargados apropiados de tomar las decisiones, no tendrán valor.
Proveer la salida en forma oportuna
Una de las quejas más comunes de los usuarios es que no reciben la información a tiempo para tomar las deci-
siones necesarias. Aunque la sincronización no lo es todo, sí desempeña un importante papel en cuanto a qué tan
útil será la salida. Muchos informes se requieren a diario, algunos sólo cada mes, otros anualmente y otros más
sólo por excepción. Al usar una salida basada en Web bien promocionada, también podemos solucionar algunos
problemas de sincronización de la distribución de salida. La sincronización precisa de la salida puede ser impres-
cindible para las operaciones de negocios.
Elegir el método de salida correcto
La elección del método de salida correcto para cada usuario es otro de los objetivos del diseño correcto de salida.
Gran parte de la salida aparece ahora en pantallas donde los usuarios tienen la opción de imprimirla. El analista
necesita reconocer los conflictos involucrados en el proceso de elegir un método de salida. Los costos difieren;
para el usuario también hay diferencias en cuanto a accesibilidad, flexibilidad, durabilidad, distribución, posibi-
lidades de almacenamiento y recuperación, capacidad de transportación e impacto general de los datos. La elec-
ción de los métodos de salida no es trivial y tampoco es una cuestión resuelta.
RELACIONAR EL CONTENIDO DE LA SALIDA CON EL MÉTODO DE SALIDA
Debemos considerar que el contenido de la salida de los sistemas de información está interrelacionado con el
método de salida. Cada vez que diseñamos la salida, necesitamos pensar acerca de cómo la función influye sobre
la forma y cómo influirá el propósito previsto en el método de salida que seleccionemos.
Debemos pensar sobre la salida en sentido general, de manera que cualquier información que produzca el
sistema computarizado y que sea útil para las personas se pueda considerar como salida. Es posible conceptua-
lizar la salida como externa (que sale de la empresa); por ejemplo, la información que aparece en el sitio Web
para el público, o como interna (que permanece dentro del negocio); por ejemplo, el material disponible en una
intranet.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 331
Marque esta casilla si tiene nueva
dirección y escríbala a continuación.
1000 N St.
Lincoln, NE 68501
Número de cuenta
640-056-175
Indique el monto
a pagar
Eckert Caryn S
123 Oak Street
Lincoln, NE 68501
Monto vencido
$17.38
Dirección de servicio Número de cuenta
640-056-175
Lectura anterior
1517
Fecha de facturación
7/8/2009
Lectura actual
1547
Fecha en que se
debe recibir el pago
para poder acreditarlo
en la siguiente factura
5 de ago de 2009
El cliente escribe
el monto del pago
en esta área.
El logotipo y
nombre de la
empresa están
pre-impresos en la
factura.
Se provee un área
para que los
clientes
proporcionen una
nueva dirección.
Una computadora
imprime la
información sobre
la cuenta.
FIGURA 11.1
Un documento retornable para el
procesamiento de datos de
Minigasco.
La salida externa es algo con lo que estamos familiarizados: facturas, anuncios, cheques de nómina, infor-
mes anuales y una multitud de comunicaciones que tienen las organizaciones con sus clientes, distribuidores,
proveedores, industria y competidores. El analista diseña una parte de esta salida, como las facturas de los servi-
cios públicos, para que sirva una doble función como documento retornable. La figura 11.1 es un recibo de gas
que sirve como documento retornable para el procesamiento de datos de la compañía de gas. La salida de una
etapa del procesamiento se convierte en la entrada para la siguiente. Cuando el cliente devuelve la parte desig-
nada del documento, se digitaliza esta parte y se utiliza como entrada de computadora.
La salida externa difiere de la interna en cuanto a su distribución, diseño y apariencia. Muchos documentos
externos deben incluir instrucciones para que el receptor pueda utilizarlos en forma correcta. Muchas salidas ex-
ternas se colocan en formularios impresos o en sitios Web que muestran el logotipo de la empresa y los colores
corporativos.
Las salidas internas incluyen varios informes para los encargados de tomar decisiones. Varían desde infor-
mes cortos y sintetizados hasta los largos y detallados. Un ejemplo de informe sintetizado es un informe que
presenta sólo los totales de las ventas mensuales; un informe detallado podría mostrar las ventas semanales por
vendedor.
Otros tipos de informes internos incluyen los informes históricos y los informes de excepciones que se
producen como salida sólo en el momento en que ocurre una excepción. Algunos ejemplos de informes de ex-
cepciones son el listado de todos los empleados sin faltas en todo el año, un listado de todos los vendedores que
no cumplieron con su cuota de ventas mensual o un informe sobre las quejas de los consumidores durante los
últimos seis meses.
Tecnologías de salida
Para producir diferentes tipos de salida se requieren distintas tecnologías. Para la salida impresa, las opciones in-
cluyen una amplia variedad de impresoras. Para la salida en pantalla, las opciones incluyen pantallas conectadas
o independientes. La salida de audio se puede amplificar a través de un altavoz o escuchar a través de bocinas,
que pueden variar desde las más pequeñas hasta los sistemas de sonido envolvente para PC. También se puede
diseñar la salida de audio para teléfonos móviles. La salida electrónica se crea mediante herramientas de soft-
ware especiales. Como podemos ver, las opciones son numerosas. La figura 11.2 muestra una comparación de
los métodos de salida.
IMPRESORAS Como los informes impresos son un tipo muy común de salida, es lógico suponer que las impresoras
están omnipresentes en cualquier organización grande. Aunque hay otros tipos de salida que están ganando
popularidad, es probable que los negocios sigan deseando la salida impresa, o que quieran diseñar salida con una
buena apariencia si los clientes, proveedores o distribuidores la imprimen mediante su propio software y hardware.www.xlibros.com

332 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Pantalla • Interactiva
Transmisión en línea y tiempo real
Silenciosa
Aprovecha las capacidades de la computadora para
desplazarse por las bases de datos y los archivos
Buena para los mensajes efímeros con acceso
frecuente
• Puede requerir cables y espacio para su instalación
De todas formas se puede requerir documentación
impresa
• •
•
•
•
Salida de audio
y podcasts
• Buena para usuarios individuales
Buena para mensajes transientes
Buena en donde el trabajador necesita las manos libres
Buena si hay que distribuir la salida en áreas
muy amplias
•
• Se requieren audífonos cuando la salida no debe interferir
con otras tareas
Tiene una aplicación limitada•
•
•
DVC, CD-ROM
y CD-RW
• Tiene gran capacidad
Permite salida multimedia
• Se requiere una computadora y una pantalla para leer
los datos•
Salida electrónica
(email, sitios Web,
blogs y fuentes RSS)
• Reduce el papel
Se puede actualizar con mucha facilidad
Se puede “transmitir”
Se puede hacer interactiva
•
• No contribuye al formato (email)
Es difícil transmitir el contexto de los mensajes (email)
Los sitios Web requieren de un mantenimiento diligente
•
•
•
•
Método de salida Ventajas Desventajas
Impresora • Asequible para la mayoría de las organizaciones • Aún se requiere de intervención por parte del operador.
Problemas de compatibilidad con el software de computadora
Puede requerir provisiones especiales y costosas
Puede ser lenta, dependiendo del modelo
Poco amigable para el ambiente
• Flexible en cuanto a tipos de salida, ubicación
y capacidades
Maneja grandes volúmenes de salida
Altamente confiable, con poco tiempo de inactividad
•
•
• •
••
FIGURA 11.2
Una comparación de los métodos de salida.
Las impresoras ahora tienden a ser más flexibles, lo que se traduce en procesos de expansión de opciones
para la ubicación del sitio de impresión, alojar distintos números de caracteres por página, incluyendo diversos
estilos y fuentes, cambiar la posición de impresión en la página, incluir mayor capacidad de gráficas y color, pro-
ducir una impresión más silenciosa, proteger el ambiente, reducir el número de formularios impresos en el inven-
tario, simplificar las tareas del operador y reducir la cantidad de intervención del operador en general.
En conjunto con los usuarios, el analista de sistemas debe determinar el propósito de la impresora. Una vez
establecido esto, hay que tener en cuenta tres factores clave de las impresoras:
1. Confiabilidad.
2. Compatibilidad con software y hardware.
3. Soporte del fabricante.
PANTALLAS COMO SALIDA Las pantallas son una tecnología de salida cada vez más popular. Usadas en un
principio para la introducción de datos, las pantallas se están convirtiendo también en una tecnología viable para
muchos otros usos a medida que disminuye su tamaño y su precio, a la vez que aumenta su compatibilidad con
otros componentes del sistema.
Las pantallas tienen distintas ventajas sobre las impresoras debido a que son más silenciosas y tienen poten-
cial para la participación interactiva de los usuarios. La salida de pantalla puede ofrecer flexibilidad al permitir al
usuario cambiar la información de salida en tiempo real por medio de la eliminación, adición o modificación de
datos. Las pantallas también permiten revisar la salida almacenada por medio del acceso a (y la visualización de)
los elementos de una base de datos relevante, con lo cual cada uno de los encargados de tomar decisiones puede
dejar de almacenar impresiones redundantes.
Las pantallas como salida producen ahorros en el costo. Si los usuarios pueden realizar sus tareas al interactuar
con una pantalla tal vez no necesiten papel, con lo cual se elimina el costo de imprimir, archivar y almacenar en me-
dios físicos. Si antes se enviaba un informe por correo convencional, al convencer a los usuarios de que vean los docu-
mentos en pantalla podemos ahorrarnos los costos de correo y de impresión. Los corredores de bolsa, las compañías
telefónicas, las empresas de servicios públicos y los bancos ofrecen la entrega electrónica de la salida a sus clientes.
La visualización electrónica también puede ser conveniente desde el punto de vista del usuario. Tal vez un
usuario sólo quiera dar un vistazo a un estado de cuenta mensual para verificar que no tenga errores. Sin em-www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 333
bargo, el usuario necesita archivar ese estado de cuenta por cuestiones fiscales. Si el estado de cuenta se entrega
por correo electrónico, tal vez la copia electrónica sea todo lo que el usuario necesite. Esto ayudará a mantener
los registros y alentará en consecuencia al usuario a que prefiera el estado de cuenta electrónico en vez del im-
preso. Otra razón para preferir la salida de pantalla a la salida de papel es que es más fácil mantener actualizada
la versión electrónica.
Una desventaja potencial es la de mostrar la salida en una variedad de pantallas que utilizan distintas resolucio-
nes. Si la pantalla que se visualiza es de una página Web, el programador de la página Web necesita un plan para re-
visar las imágenes en cada resolución (por ejemplo, 800 × 600, 1600 × 1200, etcétera) y usar distintos navegado-
res para asegurarse de que las páginas tengan una apariencia similar. Si los usuarios necesitan acceso a teléfonos
inteligentes o teléfonos móviles para completar su tarea, tal vez también haya que desarrollar páginas Web especiales.
Si la salida es un informe en vez de una página Web, el analista se enfrenta al reto de resolver otros proble-
mas. Tal vez los usuarios no tengan las fuentes necesarias en sus computadoras y sus documentos de Microsoft
Word estén personalizados con márgenes inusuales. Si se envía un documento de Word por correo electrónico, el
documento con un hermoso formato en la computadora del emisor podría terminar viéndose muy mal en la pan-
talla del receptor. Una solución es la de convertir la salida a archivos PDF mediante Adobe Acrobat. Esto permite
incrustar fuentes inusuales y establecer todos los márgenes en forma apropiada sin importar qué computadora o
resolución de pantalla la despliegue.
VIDEO, AUDIO Y ANIMACIÓN Muchas de las herramientas y paquetes de aplicaciones con los que usted vaya a
trabajar le facilitarán el proceso de incluir video en las opciones de salida. El video es una forma compleja de
salida, ya que combina la solidez y el potencial impacto emocional del audio (incluyendo efectos de sonido, voz
y música) con un canal visual. Algunas aplicaciones conocidas son las que están basadas en Web. Examine la
figura 11.3: muestra una página Web que incluye seis cortos en video del Tazón del Conocimiento del Decision
Sciences Institute (DSI); en este caso es conveniente incluir salida en video del evento, pues conmemora un
aniversario importante en la historia del instituto.
Hay muchos usos para la inclusión de salida de video en las pantallas de los usuarios. Los video clips son
una salida conveniente para:
1. Complementar la salida estática.
2. Permitir una colaboración a distancia que conecte a las personas que no se pueden reunir con frecuencia, por
ejemplo, un equipo que, distribuido en puntos geográficos distantes, debe trabajar en un mismo proyecto.
3. Mostrar cómo llevar a cabo una acción, como demostrar la manera en que se debe llenar un formulario,
instalar cierto software o ensamblar un producto.
4. Proveer episodios de capacitación breves que sean específicos para un trabajo o tarea, de manera que se haga
énfasis en una nueva habilidad.
5. Desplazar el tiempo de un evento real, al grabarlo para verlo después.
6. Preservar una ocasión importante para agregarla a los archivos de una organización.
FIGURA 11.3
Se puede utilizar video de flujo
continuo en forma efectiva para
contar una historia o compartir un
evento. Esta página Web relata
un evento conocido como el Tazón
del Conocimiento de DSI.www.xlibros.com

334 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
En cierta forma, podemos considerar la salida de audio como lo opuesto a la salida impresa. La salida de
audio es transitoria, mientras que la palabra impresa es permanente. Por lo general, la salida de audio es para
beneficio de un usuario, mientras que la salida impresa se distribuye comúnmente a muchas personas. El oído
humano interpreta la salida de audio como voz, aunque en realidad se produce a través de sonidos digitales dis-
cretos que se reúnen de tal forma que se perciban como palabras continuas. Las compañías telefónicas fueron de
las primeras empresas en producir sistemas que utilizan audio para los clientes.
El sonido también puede mejorar una presentación. Podemos conseguir fácilmente música y efectos de
sonido del dominio público. Los paquetes de presentaciones como Microsoft PowerPoint permiten a los usua-
rios insertar sonido, música e incluso videos. Los archivos de sonido existen en varios formatos, pero algu-
nos de los más comunes para las PC son los archivos MP3, WMP (Windows Media Player), .aac (iTunes e
iPhone) y .WAV.
La salida de audio se utiliza para proveer de ”personal” los números telefónicos gratuitos de venta por catálogo
activos las 24 horas del día, los siete días de la semana. Mediante un sistema telefónico digital, los consumidores
pueden llamar y, en respuesta a instrucciones en salida de audio, introducen número de artículo, cantidad, precio y
su número de tarjeta de crédito. Las tiendas capturan así ventas que perderían de otra forma, ya que podría ser de-
masiado costoso contratar a empleados que se ocupen de contestar llamadas las 24 horas.
Al usar audio y sistemas telefónicos para introducir datos, asegúrese de proveer una retroalimentación apro-
piada para el usuario, como “Ha indicado treinta y tres dólares. Presione uno si es correcto. Presione dos para
cambiar”. La entrada de audio debe contar con un guión bien diseñado y una secuencia clara. Hay que mantener
las instrucciones de audio breves, para que las personas puedan recordar los segmentos iniciales.
Podcasting es la técnica de colocar archivos de voz descargables en un sitio Web. Estos archivos de voz se
pueden utilizar para informar a los clientes sobre nuevos productos o sobre el producto de la semana, proveer un
paseo por una ciudad o destino turístico, presentar noticias y muchas otras aplicaciones. La capacidad de descar-
gar archivos de audio y video ha estado disponible por un buen tiempo ya en la Web, pero el podcasting utiliza
un pequeño archivo RSS (un archivo XML) para almacenar la versión más reciente de un podcast (si los archivos
cambian con frecuencia).
La animación es otra forma de salida que podemos utilizar para mejorar un sitio Web o una presentación. La
animación es la presentación de distintas imágenes en una serie, una a la vez. Las imágenes de animaciones están
compuestas de varios elementos básicos. Los símbolos elementales pueden ser objetos abstractos o fotografías
reales, y pueden tomar distintos colores, formas y texturas. La orientación espacial ayuda al usuario a determinar
si los símbolos están o no muy relacionados entre sí. Los efectos de transición pueden ser graduales o abruptos,
al igual que en las transiciones de las diapositivas de PowerPoint. Los efectos de alteración incluyen cambiar el
color, el tamaño o la textura; además se puede incluir la transformación de la imagen a través del “morphing”.
Si se utiliza la animación para apoyar la toma de decisiones, los experimentos han demostrado que el uso de
imágenes reales en vez de abstractas produce una mejor calidad en las decisiones. Los sujetos experimentales que
vieron transiciones animadas graduales, en vez de abruptas, pudieron tomar mejores decisiones. Al usar la anima-
ción en páginas Web, tenga cuidado en mantener las secuencias armonizadas y no las atiborre de elementos.
CD-ROM Y DVD Con la creciente demanda de salida multimedia, se ha esparcido ampliamente la visualización
de material en CD-ROM. Los CD-ROM son menos vulnerables a los daños producidos por el manejo humano,
en comparación con otros tipos de salida. Los CD-ROM pueden incluir texto y gráficos a todo color, así como
música y video de movimiento continuo, por lo que como medio de salida ofrecen al diseñador una máxima
creatividad. El DVD (disco versátil digital) también es una tecnología de salida útil. Los DVD se utilizan no sólo
para salida sino también como almacenamiento de respaldo.
SALIDA ELECTRÓNICA Muchos de los nuevos sistemas basados en Web que usted diseñará tienen la capacidad de
producir salida electrónica en forma de correo electrónico, fax y mensajes de tableros electrónicos que pueden
enviarse de una computadora a otra sin necesidad de una copia impresa.
El correo electrónico se puede establecer y operar en forma interna en la organización por medio de una
intranet, o por medio de compañías de comunicaciones o proveedores de servicio en línea. Al diseñar sistemas
de correo electrónico podemos brindar soporte a la comunicación en toda la organización. Un sistema de correo
electrónico útil y flexible puede formar la base de soporte para los grupos de trabajo.
Se están diseñando dos grupos de tecnologías recientes que permiten a los usuarios extraer información de
la Web y también permiten a las organizaciones enviar información a los usuarios en forma periódica para las
organizaciones. A estas tecnologías de salida se les conoce como tecnologías push y pull, para reflejar la forma
en que los usuarios y las organizaciones buscan información en la Web y la “jalan” para descargarla o hacen que
se les envíe, o “empuje” hacia ellos.
Las fuentes RSS (sindicación realmente simple) son documentos de XML que los usuarios pueden obtener
de vínculos en páginas Web o a los que se pueden suscribir. Contienen un título, que por lo general es el mismo
nombre que el sitio Web de la fuente RSS; un vínculo, que con frecuencia es el mismo vínculo que el de la páginawww.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 335
O P O R T U N I D A D D E C O N S U L T O R Í A 1 1 . 1
¿Tu jaula o la mía?
“¿Por qué no pueden hacer esto bien? Me está distrayendo
mucho. El zoológico en Colombia me escribió sobre un tigre que
nos prestaron desde 2002. Deberían escribir a Tulsa”, exclama Ella
Fant mientras ondea una carta en el aire. Ella es la encargada en jefe
del programa de cría de animales en el zoológico Gotham.
Ella se encuentra hablando con los miembros del comité de
cinco personas del zoológico sobre las propuestas a considerar. El
comité se reúne cada mes para decidir qué animales prestar a otros
zoológicos y cuáles recibir en préstamo para criarlos. El comité está
compuesto por Ella Fant, la encargada en jefe; Ty Garr, el director
del zoológico; dos empleados del zoológico, Annie Mall y Mona
Key; y Rex Lyon, un empresario de la comunidad.
Ty pasa al frente del grupo y continúa con la reunión diciendo:
“Tenemos la posibilidad de prestar dos de nuestros monos tamarinos
dorados y tenemos también la oportunidad de actuar como casamen-
teros para dos pandas menores. Como tres de ustedes son nuevos en
el comité, hablaré brevemente sobre sus responsabilidades. Como
saben, Ella y yo nos abalanzaríamos sobre cualquier oportunidad de
atraer animales al zoológico para el programa de cría. Su deber es
evaluar los recursos financieros del zoológico y analizar las deman-
das inmediatas del mismo. También deben considerar la temporada
y nuestra capacidad de embarque, así como la de los otros zoológi-
cos que estamos considerando. Los demás zoológicos no nos cobran
nada por prestarnos sus animales para el programa de cría. Pagamos
el embarque por cualquier animal que se nos haya prestado y des-
pués los mantenemos, y eso es costoso”:
“Estamos enlazados vía Internet a una base de datos de espe-
cies seleccionadas con otros 164 zoológicos”, dice Ella para reto-
mar la historia de Ty. “Mi oficina tiene una computadora equipada
con una pantalla, puedo acceder a los registros de todos los anima-
les cautivos en el sistema, incluyendo los de los dos zoológicos con
los que estamos negociando en estos momentos”.
Mientras los miembros del comité trabajan, empiezan a hacer
preguntas: “Necesito leer información, conseguir algo de carne en
la que pueda hundir mis dientes, antes de poder decidir si el prés-
tamo de los pandas menores es una buena idea. ¿En dónde están los
datos sobre los animales que estamos considerando?”, gruñe Rex.
Annie responde, “Tenemos que ir a la oficina de Ella para
conseguirlos. Normalmente, los otros empleados que necesitan sa-
ber simplemente usan su computadora”.
Mona interviene en la discusión para decir: “También sería
genial obtener información sobre el estado actual del presupuesto.
Me volveré loca con los nuevos gastos hasta que tengamos por lo
menos un resumen de lo que estamos gastando. Apuesto a que es
bastante”.
Ty responde: “No queremos andarnos por las ramas: franca-
mente nos sentimos atrapados. Los costos de reproducir todos los
datos financieros nos parecen altos. ¡Preferiríamos invertir nuestro
dinero en reproducir especies raras y en peligro de extinción! La
papelería se multiplica por sí sola”.
El grupo se ríe con nerviosismo, pero hay un aire de expecta-
ción en la sala. El consenso es que los miembros del comité necesi-
tan más información interna sobre el estado financiero del zoológico
y los animales candidatos para préstamo.
Ella, que está consciente de que el grupo no se puede domar de
la misma forma que el anterior, dice: “El viejo comité prefería ob-
tener su información de manera informal, charlando con nosotros.
Aprovechemos esta primera reunión para descubrir los tipos de
documentos que ustedes creen que necesitan para realizar su trabajo
como comité. Los datos financieros están en una PC individual que
utiliza nuestro director financiero. Desde luego que es su bebé”.
¿Cuáles son algunos de los problemas relacionados con la sa-
lida que experimenta el comité? ¿Qué sugerencias tiene para mejo-
rar la salida para el comité? ¿Cómo pueden cumplirse las
restricciones de presupuesto del zoológico al tiempo que se permita
al comité recibir la salida que necesita para funcionar? Comente con
respecto a si la capacidad de la tecnología de salida que se utiliza
actualmente en el zoológico es la adecuada. Sugiera alternativas o
modificaciones para la salida y opciones de tecnología de salida que
podrían mejorar lo que se hace en la actualidad. (Sugerencia: con-
sidere las formas en que el comité puede aprovechar el uso de Inter-
net —por ejemplo, empleando más la Web— para obtener la salida
que necesita y debe compartir). Analice los requerimientos de sa-
lida tanto interna como externa.
Web; una descripción breve; la leyenda de copyright; el lenguaje en el que está escrito el texto, en donde se utiliza
un código estándar como en-us (para inglés-Estados Unidos); pubDate (la fecha de publicación); lastBuildDate
(la fecha en que se hizo la última modificación a la fuente RSS); imágenes; texto y demás información. Por lo ge-
neral, las fuentes RSS se marcan en una página Web mediante el texto XML o RSS blanco en un botón naranja.
Hace poco tiempo se introdujo un cuadrado naranja con tres líneas blancas que representan ondas de radio en Fi-
refox como un símbolo de botón secundario, y está ganando popularidad.
Se supone que RSS debe ser realmente simple. Está formado por una fuente (también conocida como
canal), la cual consta de un título, un vínculo y una descripción, seguida de varios artículos de noticias, cada
uno con su propio título, vínculo y descripción. Aunque se supone que debe ser simple, debe considerarse
que hay más de media docena de versiones de RSS, además de un formato de sindicación similar conocido
como Atom. Los desarrolladores pueden proveer fuentes RSS en el sitio Web de su empresa o desarrollarlos
para sus clientes.
Para leer la fuente RSS se utiliza software lector de RSS, que a menudo es un programa gratuito. Estos lec-
tores, conocidos también como agregadores de noticias, son programas que rastrean actualizaciones, descargan,
clasifican y muestran las fuentes RSS. RSS es una forma de recopilar y distribuir noticias y demás contenido
de varias fuentes. Los lectores de noticias RSS pueden ser independientes o estar integrados con el navegadorwww.xlibros.com

336 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
en forma de complementos. Al momento de escribir este libro, los lectores de noticias populares son Bloglines,
BottomFeeder, FeedDemon, MY MSN, My Yahoo!, NewsIsFree, NEWSMONSTER, Pluck, RSSBANDIT,
SHARPREADER y Wizz RSS (para el navegador Firefox). Pronto se sacudirá el mercado para los lectores RSS
y sólo sobrevivirán unos cuantos de ellos.
RSS tiene la ventaja de organizar con eficiencia las noticias y demás información proveniente de una varie-
dad de fuentes elegidas por el usuario. Además muestra las noticias más recientes primero. RSS no se limita a las
noticias; también se puede usar para llevar el registro de la revisión más reciente de un libro o manuscrito, leer
nuevas reseñas de cine y teatro, o conocer de manera anticipada el nuevo software para nuestro teléfono móvil.
TECNOLOGÍA PULL Es una importante tecnología de salida que se hizo posible gracias a la Web. Si alguna
vez ha intentado jalar información de la Web al hacer clic en vínculos, ha utilizado el tipo más básico de
tecnología pull.
En el futuro tal vez se utilicen agentes evolucionarios (programados mediante el uso de software de agente
inteligente) para ayudar a los miembros de una organización a encontrar lo que necesitan en la Web. Estos agen-
tes aliviarán parte de la carga común de los usuarios al buscar en Web, debido a que observarán y comprenderán
el comportamiento de los usuarios a medida que éstos interactúan con una variedad de material en Web, y des-
pués se pueden programar para buscar la información que desean los usuarios. De esta forma, las búsquedas en
Web serán más eficientes y efectivas para los usuarios.
TECNOLOGÍA PUSH El contenido Web e inalámbrico que se suministra por medio de la tecnología push es
otro tipo de salida que diseñan los analistas. La tecnología push se puede utilizar en la comunicación externa
para empujar (enviar en forma electrónica) la información solicitada o no solicitada a un cliente o consumidor.
También se puede utilizar dentro de la organización para obtener la atención inmediata de un empleado o de
alguien encargado de tomar decisiones que se enfrente a un plazo crítico para entregar elementos críticos. El
término tecnología push se puede describir como cualquier tipo de contenido que se envía a los usuarios en
tiempos especificados, desde webcasting básico hasta la entrega de contenido selectivo mediante el uso de
sofisticados agentes de filtrado evolucionarios.
Muchas empresas tanto tradicionales como basadas en Internet están experimentando con la tecnología
push. Esta tecnología puede obtener la información para la persona que la necesita. Es menos costoso transmitir
información a todos los empleados que imprimir la información y después distribuirla a unos cuantos seleccio-
nados. Sin embargo, el analista necesita protegerse para evitar inundar a los empleados al publicar información
sin sentido.
Las tecnologías push son muy flexibles. Por ejemplo, cuando se transmite la salida de una intranet a una PC,
el usuario puede tomarla y personalizarla de muchas formas. Tal vez un empleado decida ver un solo producto o
desee generar una gráfica de las ventas a través del tiempo.
Factores a considerar al elegir la tecnología de salida
Al seleccionar tecnología de salida es necesario considerar ciertos factores, algunos de los cuales se mantienen
estables aunque la tecnología evolucione. Considere que en algunos casos deberá elegir o uno u otro. Los princi-
pales factores a considerar son:
1. ¿Quién utilizará (verá) la salida (calidad requerida)?
2. ¿Cuántas personas necesitan la salida?
3. ¿Dónde se necesita la salida (distribución, logística)?
4. ¿Cuál es el propósito de la salida? ¿Qué tareas de usuario y organizacionales se admiten?
5. ¿Cuál es la velocidad con la que se necesita la salida?
6. ¿Con qué frecuencia se accederá a la salida?
7. ¿Cuánto tiempo se almacenará (o se debe almacenar) la salida?
8. ¿Bajo qué leyes especiales se produce, almacena y distribuye la salida?
9. ¿Cuáles son los costos iniciales y continuos del mantenimiento y los suministros?
10. ¿Cuáles son los requerimientos humanos y ambientales (accesibilidad, absorción de ruido, temperatura
controlada, espacio para equipo, cableado y proximidad a los transmisores o puntos de acceso Wi-Fi; es
decir, los “”puntos calientes” o hot spots) para las tecnologías de salida?
Al examinar cada factor por separado, usted podrá ver las interrelaciones y cómo se pueden realizar concesiones
entre uno y otro en un sistema específico.
¿QUIÉN UTILIZARÁ (VERÁ) LA SALIDA? Es importante descubrir quién utilizará la salida, ya que los requeri-
mientos de trabajo ayudan a dictar cuál es el método de salida apropiado. Por ejemplo, cuando los gerentes
de distrito deben estar alejados de sus escritorios por periodos extendidos, necesitan salida impresa que pueda
viajar con ellos, o tecnología que pueda acceder a los sitios Web y bases de datos apropiadas mientras visitanwww.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 337
a los gerentes en su región. La salida de pantalla o los documentos Web interactivos son excelentes para
personas tales como los despachadores de camiones que permanecen sentados en su escritorio por largos
periodos de tiempo.
Los recipientes externos de la salida (clientes y consumidores, distribuidores y proveedores, accionistas y
agencias regulatorias) y los usuarios dentro de las empresas requerirán de una salida distinta. Los clientes, dis-
tribuidores y proveedores pueden ser parte de varias extranets, que son redes de computadoras construidas por la
organización y proveen aplicaciones, procesamiento e información a los usuarios en la red.
Examine el sitio Web que se muestra en la figura 11.4 para una empresa de comercio electrónico llamada
Merchants Bay. El diseñador Web está compenetrado con los usuarios previstos del sitio de regalos de mayoreo.
El sitio Web de la empresa de comercio electrónico está operado por un algoritmo de negociación patentado, en
el cual los usuarios envían sus ofertas (por 1 artículo o por 400) en una matriz de mercancía. La estrategia de la
empresa se basa en la experiencia personal del presidente con los mercados callejeros y la observación de que
hay una atracción muy poderosa entre las personas y regatear por un artículo.
El sitio Web invoca de manera intencional una sensación de amontonamiento, similar a la sensación que
se obtiene al caminar por un mercado callejero. El sitio está previsto para los clientes que frecuentan mercados
callejeros en persona: se sabe que son coleccionistas, sociables y curiosos por naturaleza. El sitio Web muestra
profusión de colores, incluye una variedad de anuncios de venta en una mezcla de letras e incluso incorpora un
video que proporciona nuevas capas de color y acción. Se utiliza un lenguaje coloquial en todo el sitio.
Cabe mencionar que el eslogan de la empresa es “proveedor de buena mercancía”. El diseñador Web ha
empleado una metáfora náutica en todo el sitio. Se invita al usuario a “buscar en la bahía” para ver toda la mer-
cancía. Además, el logotipo de la empresa incluye una ola y un sol en el horizonte, y hay un icono del timón de
un barco colocado encima de una columna para invitar al usuario a “navegar” en busca de productos, servicios y
servicio al cliente.
Para completar una transacción en el sitio, el cliente tiene la oportunidad de aceptar el “precio del capitán”
publicado, o puede enviar una oferta. Si se envía una oferta demasiado baja de acuerdo con el algoritmo de ne-
gociación almacenado, se devuelve una respuesta en lenguaje natural en una ventana desplegable, la cual dice:
“Gracias por su oferta, marinero. No le gusta deshacerse de su dinero si no tiene que hacerlo, ¿verdad? Aún así
me simpatiza, marinero. Intente de nuevo y ofrezca un mejor precio, o pida una cantidad mayor”. De esta forma,
la oferta se rechaza de una manera amigable y humorística, y las personas que ofertan reciben dos sugerencias
sobre cómo mejorar la probabilidad de que sus siguientes ofertas tengan éxito. Sin duda, el diseñador Web tenía
en mente un sólido perfil del cliente previsto al diseñar el sitio.
¿CUÁNTAS PERSONAS NECESITAN LA SALIDA? La elección de la tecnología de salida también se ve influenciada por
la cantidad de usuarios que requieren la salida. Si muchas personas necesitan la salida, probablemente se justifique
el uso de documentos basados en Web con opción para imprimir o copias impresas. Tal vez algunos clientes
externos quieran una copia impresa de documentos específicos, como el informe para un accionista o un estado de
FIGURA 11.4
Al diseñar un sitio Web, es
importante elegir una metáfora
que se pueda utilizar en todo el
sitio. Este ejemplo de Merchants
Bay (www.merchantsbay.com)
emplea un tema náutico.www.xlibros.com

338 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
cuenta de facturación mensual, pero otros podrían preferir documentos basados en Web con una notificación vía
correo electrónico. Si sólo un usuario necesita la salida, podría ser más adecuado usar una pantalla o audio.
Si muchos usuarios en la empresa necesitan distintas opciones de salida en distintos momentos durante pe-
riodos cortos y la necesitan con rapidez, los documentos Web o pantallas conectadas a terminales en línea que
puedan acceder al contenido de bases de datos son una opción viable.
¿DÓNDE SE NECESITA LA SALIDA (DISTRIBUCIÓN, LOGÍSTICA)? La elección de la tecnología de salida también se
ve influenciada por el destino físico de la salida. La información que permanecerá cerca de su punto de origen,
que sólo unos cuantos usuarios en la empresa utilizarán y que tal vez se almacene o use con frecuencia, se puede
imprimir o montar en una intranet sin peligro. Una cantidad abundante de información que se deba transmitir a
los usuarios a través de grandes distancias en operaciones con sucursales tal vez se distribuya mejor en forma
electrónica, a través de la Web o de extranets, y el receptor puede personalizarla.
Algunas veces, las leyes federales o estatales dictan que un formulario impreso debe permanecer en los ar-
chivos en una ubicación específica y durante un periodo especificado. En esos casos es responsabilidad del ana-
lista de sistemas asegurarse que se cumpla con las leyes para cualquier salida que se diseñe.
¿CUÁL ES EL PROPÓSITO DE LA SALIDA?. ¿Qué tareas de usuario y organizacionales se aceptan? Considere el
propósito de la salida al momento de elegir la tecnología de salida. Si está destinada a ser un informe creado para
atraer accionistas a la empresa, al permitirles examinar las finanzas corporativas a sus anchas, es conveniente una
salida impresa bien diseñada tal como un informe anual. También se puede utilizar una variedad de medios de
manera que el informe anual esté disponible en la Web, así como en forma impresa.
Si el propósito de la salida es proveer actualizaciones instantáneas sobre las cotizaciones en la bolsa, y si
el material cuenta con un alto grado de codificación y puede cambiar, es más adecuado el uso de una pantalla,
páginas Web o presentaciones de audio. La salida debe brindar soporte a las tareas de los usuarios, como la rea-
lización de análisis o la determinación de proporciones, de forma que las herramientas de software, incluyendo
calculadoras y fórmulas incrustadas, podrían ser parte de la salida. También deben brindar soporte a las tareas
organizacionales como el rastreo, la calendarización y la supervisión.
¿CUÁL ES LA VELOCIDAD CON LA QUE SE NECESITA LA SALIDA? Al avanzar por los tres niveles de administración
estratégica, media y de operaciones en la organización, descubrimos que los encargados de tomar decisiones
en el nivel más bajo de la administración de operaciones necesitan la salida con rapidez, para poder ajustarse
rápidamente a eventos como una línea de ensamblaje detenida, materia prima demorada o un trabajador ausente
en forma inesperada. Aquí podría ser útil la salida de pantalla.
Al subir por los niveles administrativos observamos que los gerentes estratégicos necesitan más la salida du-
rante un periodo específico, lo cual ayuda a pronosticar los ciclos y las tendencias de negocios.
¿CON QUÉ FRECUENCIA SE ACCEDERÁ A LA SALIDA? Entre más frecuente sea el acceso a la salida, más importante
será la capacidad de verla en una pantalla conectada a las redes de área local o la Web. La salida a la que se accede
con poca frecuencia y que sólo unos cuantos usuarios necesitan es ideal para un archivo de CD-ROM.
La salida a la que se accede con frecuencia es ideal para incorporarla en los sistemas basados en Web u otros
sistemas o redes en línea con pantallas. Al adoptar este tipo de tecnología, los usuarios obtienen un acceso oportuno y
se alivian el uso y desgaste físicos que producen deterioro en la salida impresa que se maneja con frecuencia.
¿CUÁNTO TIEMPO SE ALMACENARÁ (O SE DEBE ALMACENAR) LA SALIDA? La salida impresa en papel se deteriora
con rapidez a través del tiempo. La salida que se preserva en microformas o que se digitaliza en archivos no es
tan propensa a sucumbir a los disturbios ambientales como la iluminación, la humedad y el manejo humano.
Pero si el hardware para acceder al material archivado es difícil de adquirir o se vuelve obsoleto, este método de
salida puede volverse problemático.
Tal vez una empresa esté sujeta a las leyes gubernamentales en los niveles local, estatal o federal, que dicten
cuánto tiempo se debe mantener guardada la salida. Mientras que la corporación esté dispuesta a mantener la sa-
lida y ésta sea información de archivo no propietaria, se puede mantener en documentos Web como parte del si-
tio Web de la organización. Las organizaciones pueden establecer sus propias políticas internas acerca de cuánto
tiempo se debe retener la salida.
¿BAJO QUÉ LEYES ESPECIALES SE PRODUCE, ALMACENA Y DISTRIBUYE LA SALIDA? El gobierno se encarga de
regular el formato apropiado para ciertos tipos de salida. Por ejemplo, en los Estados Unidos la declaración
del salario y la retención de impuestos de un empleado, a lo cual se le conoce como formulario W-2, se debe
imprimir; su formato final no puede ser una salida de pantalla o microforma. Cada empresa en cada país existe
dentro de un complejo distinto de leyes bajo las cuales produce la salida. Para tal efecto, la ley puede dictar la
tecnología apropiada para ciertas funciones.
Sin embargo, gran parte de estas leyes dependen de la industria. Por ejemplo, en los Estados Unidos la ley federal
requiere que un banco de sangre regional mantenga un historial médico de un donador de sangre (así como su nombre)
en archivo. No se especifica el formato exacto de la salida, pero el contenido está descrito en forma minuciosa.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 339
¿CUÁLES SON LOS COSTOS INICIALES Y CONTINUOS DEL MANTENIMIENTO Y LOS SUMINISTROS? Los costos
iniciales relacionados con la compra o renta de equipo se deben considerar como otro factor más que participa en
la elección de la tecnología de salida. La mayoría de los distribuidores le ayudarán a estimar los costos iniciales
de comprar o rentar hardware de computadora, incluyendo el costo de las impresoras y pantallas, el costo del
acceso a los proveedores de servicio en línea (acceso a Internet) o los costos de construir intranets y extranets.
Sin embargo, muchos distribuidores no proveen información sobre cuánto cuesta mantener una impresora o
hacer funcionar otras tecnologías. Por lo tanto, es responsabilidad del analista investigar los costos de operación
de las distintas tecnologías de salida o de mantener un sitio Web corporativo a largo plazo.
¿CUÁLES SON LOS REQUERIMIENTOS AMBIENTALES HUMANOS PARA LAS TECNOLOGÍAS DE SALIDA? Los
analistas necesitan incluir en sus decisiones sobre la salida los factores correspondientes a accesibilidad,
absorción de ruido, temperatura controlada, espacio para el equipo, cableado y proximidad a los transmisores
Wi-Fi o puntos de acceso o “puntos calientes”. Cuando los humanos interactúan con las tecnologías, los
ambientes específicos ayudan a los sistemas a operar con mayor efectividad y eficiencia. Los usuarios necesitan
accesibilidad y soporte para acceder a las páginas Web, así como a los demás tipos de salida.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 1 . 2
Una vía correcta, una equivocada y una vía de metro
“Hasta ahora todo está bien. Es cierto que hemos tenido algunas
quejas, pero cualquier nuevo metro subterráneo las tiene. El ardid
publicitario del “viaje gratis” ayudó a atraer personas que nunca
hubieran viajado en otras circunstancias. Creo que hay más personas
interesadas en viajar en el metro subterráneo de las que había antes”,
dice Bart Rayl. “Lo que necesitamos es una idea precisa sobre el
número de pasajeros hasta ahora, para poder realizar algunos ajustes
en nuestras decisiones sobre la tarifa y el itinerario de los trenes”.
Rayl es gerente de operaciones para S.W.I.F.T, el metro subte-
rráneo recién construido para Western Ipswich y Fremont Trans-
port, el cual da servicio a una de las principales ciudades al noreste
de los Estados Unidos. Se encuentra hablando con Benton Turns-
tile, quien se reporta a él como supervisor de operaciones de
S.W.I.F.T. El sistema de metro subterráneo está en su primer mes
de operación, en el que ofrece líneas limitadas. La gente de marke-
ting ha estado regalando viajes gratis en el metro para aumentar la
conciencia pública sobre S.W.I.F.T.
“Creo que es una buena idea”, dice Turnstile. “No es sólo un
esfuerzo simbólico. Les mostraremos que realmente estamos en el
carril correcto. Volveré pronto con usted para mostrarle la informa-
ción sobre el número de pasajeros”, dice.
Un mes después, Rayl y Turnstile se reúnen para comparar el
número de pasajeros proyectado con los nuevos datos. Turnstile pre-
senta con orgullo a Rayl una pila de dos pulgadas de alto de impresio-
nes de computadora. Rayl se ve un poco sorprendido, pero procede a
repasar los documentos con Turnstile. “¿Qué tenemos aquí?” pregunta
Ray, pasando el dedo índice sobre la página superior de la pila.
“Bueno,” dice Turnstile al tiempo que pone sus ojos en las
impresiones, “es una lista de todos los boletos que se vendieron en
las máquinas computarizadas. Nos indica cuántos boletos se com-
praron y qué tipo de boletos fueron. Los de Systems That Think,
Inc. me dijeron que este informe sería muy útil para nosotros, al
igual que para las personas de operaciones en Buffalo y Pittsburgh”,
dice Turnstile, volteando rápidamente la siguiente página,.
“Tal vez, pero recuerda que esos sistemas de metro subterrá-
neo empezaron con un servicio realmente limitado. Nosotros somos
más grandes. ¿Y qué hay sobre las ventas de las tres casetas de
boletos en la terminal de Main Street?”, pregunta Rayl.
“Los empleados en la caseta pueden obtener información que
sintetiza las ventas de boletos en pantalla cada vez que lo requieran,
pero esa información no está incluida aquí. Recuerda que proyecta-
mos que sólo el 10 por ciento de nuestras ventas serían de las case-
tas, de todas formas. Sigamos con nuestra idea original y agreguemos
esa información a las copias impresas”, sugiere Turnstile.
Rayl responde: “Pero he estado observando a los pasajeros. La
mitad de ellos parecen tener miedo de las máquinas expendedoras de
boletos. Otros empiezan a usarlas, se frustran al tratar de leer las
instrucciones o no saben qué hacer con el boleto que sale y terminan
en la caseta de boletos a punto de estallar de coraje. Además, no
pueden entender la información de rutina que se publica en los quios-
cos, pues está en forma de gráficos. Terminan preguntando a los
empleados qué tren va para qué lado”. Rayl empuja los papeles que
contienen las ventas de boletos hacia un lado de la mesa de conferen-
cias y dice: “No tengo mucha confianza en este informe. Siento como
si estuviéramos sentados aquí tratando de operar el sistema de metro
subterráneo más sofisticado de los Estados Unidos mirando fijamente
un túnel en vez de la información, como deberíamos. Creo que nece-
sitamos pensar seriamente sobre cómo capturar la información de los
viajes en tarjetas con cintas magnéticas como lo hace la Autoridad de
tránsito de la ciudad de Nueva York. Cada vez que uno inserta una
tarjeta para viajar se almacena la información”.
¿Cuáles son algunos de los problemas específicos con la salida
que los consultores de sistemas y Benton Turnstile dieron a Bart
Rayl? Evalúe los medios que se están usando para la salida, así
como la sincronización de su distribución. Comente sobre la salida
externa que aparentemente reciben los usuarios de las máquinas
expendedoras de boletos. Sugiera algunos cambios en la salida para
ayudar a Rayl a obtener la información que necesita para tomar
decisiones sobre las tarifas y los itinerarios de los trenes, y para
ayudar a los usuarios del sistema de metro subterráneo a obtener la
información que necesitan. ¿Cuáles son algunas de las decisiones a
las que se enfrentan las organizaciones como la Autoridad de trán-
sito de Nueva York si recolectan y almacenan la entrada concer-
niente a los destinos de un individuo cada vez que éste hace un
viaje? ¿Qué cambios tendría que hacer S.W.I.F.T. en cuanto a su
salida y sus boletos si adoptara esta tecnología?www.xlibros.com

340 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Las impresoras requieren un entorno seco y frío para operar en forma apropiada. Las pantallas requieren
espacio para instalarlas y verlas. La salida de audio y video requiere un entorno silencioso para poder escuchar;
además sólo los empleados (o clientes) que la utilizan deben ser quienes puedan escuchar. Por ende, el analista
no debe especificar una salida de audio para una situación de trabajo en la que haya muchos empleados o clientes
involucrados en una variedad de tareas no relacionadas con la salida.
Para poder establecer redes de área local inalámbricas, de manera que los usuarios puedan acceder a la Web sin
necesidad de cables, debe haber puntos de acceso Wi-Fi disponibles. Estos funcionan cuando las PC están a unos
cuantos cientos de pies de los transmisores, pero pueden estar sujetos a interferencia debido a otros dispositivos.
Algunas tecnologías de salida se valoran por ser discretas. Las bibliotecas, que hacen énfasis en mantener
silencioso el sitio de trabajo, utilizan mucho las pantallas para los documentos Web y demás información de base
de datos en red, pero usan muy pocas impresoras.
COMPRENDER CÓMO AFECTA LA PREDISPOSICIÓN EN LA SALIDA A LOS USUARIOS
La salida no es sólo un producto neutral que los encargados de tomar decisiones analizan para luego actuar con
base en ella. La salida afecta a los usuarios en muchas formas distintas. Los analistas de sistemas deben tener
mucha creatividad y cautela al diseñar la salida para evitar las predisposiciones.
Cómo reconocer la predisposición en la forma en que se utiliza la salida
Un error común es suponer que una vez que el analista de sistemas aprueba un proyecto de sistemas termina el
impacto que puede generar sobre éste. En realidad, la influencia del analista es de larga duración. La mayor parte
de la información en la que los miembros de la organización basan sus decisiones se determina con base en lo
que los analistas perciben como importante para la empresa.
La predisposición está presente en todo lo que crean los humanos. No pretendemos con esto decir que la pre-
disposición es mala, sino enfatizar que es inseparable de lo que nosotros producimos y, consecuentemente, de lo
que nuestro sistemas producen. Las preocupaciones de los analistas de sistemas son evitar predisponer la salida sin
necesidad y hacer que los usuarios tomen conciencia de las posibles predisposiciones en la salida que reciben.
Las presentaciones de la salida se predisponen involuntariamente en tres formas principales:
1. En el orden de la información.
2. En el establecimiento de los límites aceptables.
3. En la elección de las gráficas.
CÓMO SE INTRODUCE LA PREDISPOSICIÓN AL ORDENAR LA INFORMACIÓN La predisposición se introduce a la
salida cuando el analista y los usuarios hacen elecciones acerca de cómo ordenar la información para un informe.
Las formas comunes de ordenar información son por orden alfabético, por orden cronológico y por costo.
La información que se presenta en orden alfabético puede enfatizar excesivamente los elementos que em-
piezan con las letras A y B, ya que los usuarios tienden a poner más atención a la información que se presenta
primero. Por ejemplo, si los proveedores anteriores se listan por orden alfabético, las empresas como Aardvark
Printers, Advent Supplies y Barkley Office Equipment se muestran primero al gerente de compras. Cuando cier-
tas aerolíneas crearon los sistemas de reservaciones SABRE y APOLLO, listaban sus propios vuelos primero
hasta que las otras aerolíneas se quejaron de que había predisposición en este tipo de ordenamiento.
CÓMO SE INTRODUCE LA PREDISPOSICIÓN AL ESTABLECER LÍMITES La segunda fuente importante de
predisposición en la salida es la predefinición de límites para valores específicos en los informes. Muchos
informes se generan sólo por excepción, lo cual significa que cuando se establecen de antemano límites en los
valores, sólo se obtendrán como salida las excepciones a esos valores. Los informes por excepciones ayudan a
que el encargado de tomar decisiones tome conciencia de las desviaciones de los valores satisfactorios.
Por ejemplo, los límites que se establecen a un nivel demasiado bajo para los informes por excepciones pue-
den predisponer la percepción del usuario. Una compañía de seguros que genere informes por excepciones en
todas las cuentas con una semana de retraso en el pago establece un límite muy bajo en los pagos vencidos. El
encargado de tomar decisiones que reciba la salida se verá abrumado por “excepciones” que en realidad no son
motivo de preocupación. El informe por excepción de pagos con una semana de retraso da a los usuarios una
mala impresión de que hay muchas cuentas vencidas. Un límite más apropiado para generar un informe por ex-
cepción sería incluir las cuentas con 30 o más días de retraso.
CÓMO SE INTRODUCE LA PREDISPOSICIÓN A TRAVÉS DE GRÁFICAS La salida está sujeta a un tercer tipo de
predisposición en la presentación: la elección del analista (o usuario) en cuanto a las gráficas para mostrar la salida.
La predisposición puede ocurrir al seleccionar el tamaño, su color, la escala a utilizar e incluso el tipo de gráfica.
El tamaño de la gráfica debe ser proporcional, de manera que el usuario no esté predispuesto en cuanto a la impor-
tancia de las variables que se presentan. Por ejemplo, la figura 11.5 muestra una gráfica de columnas en el que se comparawww.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 341
Este diagrama no
muestra el
panorama real.Número de
reservaciones
no completadas
400
410
420
430
440
450
2008 2009
FIGURA 11.5
Es muy probable que un gráfico
desorientador predisponga al
usuario.
el número de reservaciones de hotel no completadas en el 2008 con las reservaciones de hotel no completadas en el 2009.
Observe que el eje vertical está roto y parece ser que el número de reservaciones no completadas para el 2008 es dos ve-
ces mayor que el número de reservaciones no completadas en el 2009, aunque en realidad ha aumentado sólo un poco.
Cómo evitar la predisposición al diseñar la salida
Los analistas de sistemas pueden usar estrategias específicas para evitar predisponer la salida que ellos y otros diseñan:
1. Estar consciente de las fuentes de predisposición.
2. Crear un diseño interactivo de la salida durante la creación de prototipos, fase en la que se incluya a los
usuarios y una variedad de sistemas configurados en forma distinta al momento de evaluar la apariencia de
los documentos Web.
3. Trabajar con los usuarios de manera que estén informados de las predisposiciones de la salida y puedan
reconocer las implicaciones al personalizar sus pantallas.
4. Crear una salida flexible que permita a los usuarios modificar límites y rangos.
5. Capacitar a los usuarios para que se basen en varias salidas para realizar “pruebas de realidad” con la salida
del sistema.
Todas estas estrategias (excepto la primera) se enfocan en la relación entre el analista del sistema y el usuario, y la
forma en que esta relación se involucra con la salida. En primer lugar, los analistas de sistemas necesitan reconocer
el impacto potencial de la salida y estar conscientes de las posibles formas en que se puede predisponer involunta-
riamente la salida. Después, necesitan ser propositivos para ayudar a los usuarios a diseñar una salida con el menor
grado de predisposición, sin perder la capacidad de identificar esta.
Cómo diseñar la salida impresa
La fuente de información que debemos incluir en los informes es el diccionario de datos, la compilación de lo
que vimos en el capítulo 8. Recuerde que el diccionario de datos incluye los nombres de los elementos de datos,
así como la longitud de campo requerida para cada entrada.
Los informes se clasifican en tres categorías: detallados, por excepciones y sintetizados. Los informes deta-
llados imprimen una línea por cada registro en el archivo maestro. Se utilizan para enviar correspondencia a los
clientes, enviar las calificaciones de los estudiantes, imprimir catálogos, etcétera. Las pantallas de consulta han
sustituido a muchos informes.
Los informes por excepciones imprimen una línea para todos los registros que coincidan con un conjunto de con-
diciones, como cuáles serán las decoraciones de días festivos que tendrán un descuento un día después del día festivo,
o cuáles estudiantes estarán en la lista de honor. Por lo general se utilizan para ayudar a los gerentes de operaciones y
al personal de oficina a operar un negocio. Los informes sintetizados imprimen una línea para un grupo de registros
y se utilizan para tomar decisiones, como cuáles son los artículos que no se venden y cuáles se venden mucho.
Lineamientos para el diseño de informes impresos
La figura 11.6 es un informe de salida previsto para los gerentes divisionales de un mayorista de alimentos que
abastece a varias tiendas de abarrotes de franquicia. Nos enfocaremos en diversos aspectos del informe a medida
que examinemos herramientas, convenciones y atributos funcionales y de estilo de los informes de salida impresos.
CONVENCIONES DE DISEÑO DE LOS INFORMES Las convenciones a seguir al momento de diseñar un formulario
incluyen el tipo de datos (alfabético, especial o numérico) que aparecerá en cada posición, mostrar el tamaño del
formulario que se está preparando y mostrar la forma de indicar que los datos continúan en formularios dispuestos
en forma consecutiva. La mayoría del software de diseño de formularios que utilizan los analistas en la actualidad
posee convenciones estandarizadas para diseñar formularios en pantalla. Además se incluyen interfaces familiares
tipo “arrastrar y soltar” que nos permiten seleccionar atributos con el ratón, como un bloque de direcciones, parawww.xlibros.com

342 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U L T O R Í A 1 1 . 3
¿Debería prohibirse esta gráfica?
“Cielos, estoy contento de que los contrataran, muchachos. Se
que a los Redwings les irá mejor la siguiente temporada debido a us-
tedes. Mi trabajo será mucho más sencillo también”, dice Andy Skors,
gerente de boletos para el equipo de hockey de Kitchener, Ontario, los
Kitchener Redwings. Andy ha estado trabajando con el equipo de
analistas de sistemas al que usted pertenece para analizar los requeri-
mientos de sistemas para computarizar las ventas de boletos.
Hay que recordar que la última vez que hablamos sobre el
equipo de análisis de sistemas, que consistía de Hy Sticking (su lí-
der), Rip Shinpadd, Fiona Wrink y usted, estaban discutiendo sobre
agilizar el proyecto y establecer los objetivos de productividad del
equipo (en “Cuidar los objetivos”, Oportunidad de consultoría 3.5).
Andy está hablando con el equipo sobre lo que se debe incluir
en la propuesta de sistemas para hacerla lo más convincente posible
para la gerencia de los Redwings. “Estoy seguro de que les gustará
esta gráfica”, continúa Andy. “Es algo simple que dibujé después de
que usted me hizo todas esas preguntas sobre las ventas anteriores
de boletos, Rip”.
Andy entrega la gráfica de barras a Rip, quien lo ve y deja
entrever una ligera sonrisa. “Ya que estás aquí con nosotros, Andy,
¿por qué no lo explicas?”.
Como un jugador que acaba de salir de la caja de castigos,
Andy empieza a explicar la gráfica como si estuviera patinando con
estilo y gracia. “Bueno, nuestras ventas de boletos llegaron a su
máximo histórico en 2007. La multitud estuvo realmente compla-
cida ese año. Incluso podríamos haber vendido asientos en el mar-
cador si me hubieran dejado. Por desgracia, las ventas de boletos
llegaron a su mínimo histórico en 2009. Es decir, realmente fue un
desastre. Los boletos se movían más lento que un glaciar. Tuve que
convencer a los jugadores para que regalaran boletos cuando hicie-
ran apariciones en el centro comercial. Si dan un vistazo a esta ta-
bla, se darán cuenta de lo que hablo”.
“Pienso que al computarizar las ventas de boletos podernos
elegir quiénes serán nuestros patrocinadores de la temporada. Tene-
mos que averiguar quiénes son y recuperarlos, hacer que sigan con
nosotros. Eso sería una excelente meta a lograr”, concluye Andy.
Después de la agitada presentación de Andy, Hy mira como si
pensara que el periodo de 20 minutos nunca acabaría. Al entender
su señal, Fiona dice: “Gracias por la información, Andy. Trabajare-
mos para incluirla en el informe de alguna forma”.
Mientras Fiona y Rip salen de la sala con Andy, Hy se da cuenta
de que ya no queda nadie en la banca, por lo que le pide a usted, el
cuarto miembro del equipo, que guíe a Andy con su gráfica de ba-
rras; haga una lista de los problemas que vea en él. A Hy también le
gustaría que usted hiciera bosquejos de algunas formas alternativas
de graficar los datos sobre las ventas de boletos, de manera que se
pueda incluir una gráfica correcta y persuasiva sobre las ventas de
boletos en la propuesta de sistemas. Dibuje dos alternativas.
2009
2008
2005
2006
2007
11,000 12,000 13,000 14,000 15,000
5,000 6,000 7,000 8,000 9,000 10,000
¿Qué tiene de
malo este
gráfico?
2007
2006
2005
2008
2009
Mejor año
Peor año
15,643
14,880
14,100
13,254
12,690
7,505
6,808
7,089
6,735
6,351
Estado Año
Promedio
boletos
vendidos
por juego
Boletos de
temporada
vendidos
por temporada
FIGURA 11.C1
Un gráfico dibujado en forma incorrecta.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 343
C 5 1 1 2 F r o n t R o y a l , V A 2 0 2 3 5 1 1 2 6 5 3 . 9 3 2 1 . 8 5 4 . 0 2 , 1 4 4 1 . 7
S 4 3 1 1 R o c k v i l l e , M D 4 0 4 1 5 2 1 4 4 6 4 . 2 7 0 0 . 3 4 3 . 1 2 , 0 6 2 1 . 4
R 3 0 2 1 M i d d l e b u r g , V A 2 0 2 2 5 3 9 5 4 4 . 2 9 2 1 . 9 4 4 . 0 2 , 0 5 7 2 . 2
S 5 0 2 1 C u l p e p e r , V A 2 0 2 6 5 4 2 1 9 8 3 . 7 8 3 1 . 5 1 0 4 . 4 2 , 0 0 5 0 . 9
R 2 8 2 0 W a l d o r f , M D 4 0 4 2 5 5 7 2 3 4 . 6 9 1 1 . 2 2 3 . 3 1 , 9 0 3 2 . 6
C 4 4 2 4 F a i r f a x - L e e H g w y 2 0 2 2 5 6 1 3 1 5 4 . 1 6 2 1 . 3 5 4 . 0 1 , 8 6 9 1 . 4
C 4 4 2 3 B a i l e y s X - R o a d s 2 0 2 2 5 7 9 8 5 4 . 7 0 2 1 . 7 5 4 . 6 1 , 7 2 7 1 . 8
S 3 8 2 1 H e r n d o n , V A 2 0 2 3 5 8 2 2 1 7 3 . 3 5 4 1 . 7 9 4 . 2 1 , 7 0 3 0 . 8
C 7 1 2 6 F r e d e r i c k , M D 3 0 3 2 5 9 1 2 5 5 4 . 0 4 2 1 . 6 5 4 . 3 1 , 6 1 5 1 . 3
S 8 0 2 9 C e n t r e v i l l e , V A 2 0 2 7 6 0 1 7 5 7 3 . 7 3 3 1 . 9 8 4 . 7 1 , 5 9 3 0 . 9
R 5 0 2 9 M i n n i e v i l l e , V A 2 0 3 4 6 1 3 4 2 5 . 2 8 1 3 . 3 1 4 . 0 1 , 5 7 2 4 . 7
S 7 5 2 0 M o u n t V e r n o n 2 0 2 4 6 2 9 0 5 5 . 2 2 2 1 . 7 5 5 . 2 1 , 5 5 8 1 . 7
C 4 7 1 2 D . C . M S t r e e t 4 0 4 4 6 3 2 3 5 1 0 4 . 3 5 4 1 . 8 1 3 5 . 5 1 , 4 8 9 0 . 6
S 4 7 1 6 A n n a n d a l e 2 0 2 5 6 4 1 2 6 6 4 . 5 2 0 0 . 1 4 3 . 5 1 , 4 5 7 1 . 2
S 7 9 2 2 V i e n n a , V A 2 0 2 5 6 5 1 7 7 9 4 . 8 6 2 1 . 2 9 5 . 3 1 , 4 4 7 0 . 8
R 4 4 9 1 G r e a t F a l l s 2 0 2 4 6 6 8 6 4 4 . 3 9 2 1 . 9 4 4 . 7 1 , 3 6 4 1 . 6
R 3 9 2 6 H a r p e r ’ s F e r r y 3 0 3 3 6 7 6 8 3 4 . 8 0 0 0 . 3 2 3 . 1 1 , 3 2 5 1 . 9
C 2 4 2 2 F a l l s C h u r c h 2 0 2 7 6 8 1 4 4 6 4 . 0 6 2 1 . 4 7 4 . 6 1 , 3 2 2 . 9
R 3 0 2 4 C l i f t o n , V A 2 0 2 3 6 9 5 3 3 5 . 1 7 1 1 . 6 2 4 . 3 1 , 2 7 3 2 . 4
C 4 5 1 1 S i l v e r S p r i n g , M D 2 0 4 2 7 0 1 2 1 5 4 . 0 6 1 1 . 2 5 4 . 3 1 , 2 3 7 1 . 0
R 5 1 2 0 O l n e y , M D 3 0 3 1 7 1 4 3 2 4 . 6 0 1 . 2 . 2 4 . 0 1 , 2 1 7 2 . 8
C 4 5 2 7 D . C C o n n e c t i c u t A v e 4 0 4 5 7 2 1 1 0 5 4 . 2 8 0 0 . 2 4 3 . 4 1 , 2 0 0 1 . 1
C 4 5 2 6 P e n n s y l v a n i a A v e 4 0 4 2 7 3 1 3 4 6 4 . 5 5 0 0 . 2 5 4 . 0 1 , 0 7 3 0 . 8
S 2 9 2 3 M a n a s s a s 2 0 2 5 7 4 1 9 8 7 3 . 5 4 0 0 . 1 6 3 . 1 1 , 0 5 7 0 . 5
T i e n d a s e n l a c i u d a d 6 , 0 2 5 2 5 5 4 . 2 3 6 7 1 . 1 1 9 0 3 . 2 6 9 , 9 8 7 1 . 2
T i e n d a s e n l o s s u b u r b i o s 3 , 4 0 2 1 7 1 5 . 0 3 5 4 1 . 6 1 3 3 3 . 9 3 5 , 0 2 0 1 . 0
T i e n d a s r u r a l e s 2 , 0 1 8 9 2 4 . 5 6 2 7 1 . 3 4 7 2 . 3 4 3 , 2 2 3 2 . 1
T o t a l ( t o d a s l a s t i e n d a s e n l a r e g i ó n ) 1 1 , 4 4 5 5 1 8 4 . 5 2 1 4 8 1 . 3 3 7 0 3 . 2 1 4 8 , 2 3 0 1 . 3
I n f o r m a c i ó n d e t i e n d a s d e f r a n q u i c i a
C l a s i f i c a d a p o r l a s g a n a n c i a s e n d ó l a r e s
P a r a e l m e s q u e t e r m i n a e n M M / D D / A A A A
D V e n t a s e n
m i l e s d e
d ó l a r e s
G a n a n c i a
b r u t a e n
m i l e s
O t r o s
i n g r e s o s
e n m i l e s
G a s t o s
a s i g n a d o s
e n m i l e s
I
I n g r e s o s
e n
d ó l a r e sF . N Ú M . N o m b r e s d e l a s t i e n d a s V D i s t R a n g o % % % %
P á g i n a 2
FIGURA 11.6
Un informe de salida impreso para los gerentes
divisionales de un mayorista de alimentos.
después soltarlo en la pantalla donde deseamos colocarlo en el formulario. Es muy común utilizar WYSIWYG (lo
que se ve es lo que se obtiene), por lo que el diseño de formularios es un ejercicio muy visual.
La información constante es información que permanece igual cada vez que se imprime el informe. El título
del informe y todos los encabezados de las columnas se escriben como información constante. La información
variable es información que puede variar cada vez que se imprime el informe. En nuestro ejemplo cambian las
cifras de ventas en miles de dólares; por ende, se indican como información variable.
CALIDAD DE PAPEL, TIPO Y TAMAÑO La salida se puede imprimir en innumerables tipos de papel. Por lo general,
la restricción primordial es el costo. Un ejemplo es el uso de papel de seguridad para los cheques y los sobres de
los cheques, así como para los documentos que deben portar sellos oficiales inalterables u hologramas, como los
pasaportes.
Los formularios pre-impresos pueden transmitir con facilidad una imagen corporativa distintiva mediante el
uso de los colores, logotipos y otros elementos de diseño relacionados con la empresa. El uso de formas, colores
y distribuciones innovadoras también es una forma efectiva de llamar la atención de los usuarios para el informe
que contiene el formulario impreso.
CONSIDERACIONES DE DISEÑO Al diseñar el informe impreso, el analista de sistemas trabaja con los usuarios
para incorporar las consideraciones funcionales y estilísticas o estéticas, de manera que el informe provea al
usuario la información necesaria en un formato legible y agradable. Como la función y la forma se refuerzan una
a otra, no hay que hacer énfasis en una a expensas de la otra.
Atributos funcionales Los atributos funcionales de un informe impreso incluyen: 1) el encabezado o título del
informe, 2) el número de página, 3) la fecha de preparación, 4) los encabezados de columnas, 5) el agrupamiento
de los elementos de datos relacionados y 6) el uso de interrupciones de control. Cada uno de estos atributos sirve
un propósito distintivo para el usuario.
Hay varias consideraciones estilísticas o estéticas que el analista de sistemas debe observar al diseñar un in-
forme impreso. Si la salida impresa es poco atractiva y difícil de leer, no se utilizará en forma efectiva o tal vez
no se utilice para nada. El resultado es la desinformación de los encargados de tomar decisiones y un desperdicio
de los recursos de la organización.www.xlibros.com

344 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Los informes impresos deben estar organizados en consideración del fluir de la vista. En esta cultura, eso
significa que el informe se debe leer de arriba hacia abajo y de izquierda a derecha. Los elementos de datos rela-
cionados se podrían agrupar entre sí. En una sección posterior de este capítulo veremos la estética sobre el diseño
de sitios y páginas Web.
CÓMO DISEÑAR SALIDA PARA PANTALLAS
En el capítulo 12 veremos cómo diseñar pantallas para entrada humana o de computadora; aquí se aplican
los mismos lineamientos para diseñar la salida, aunque el contenido varía. Cabe mencionar que la salida para
las pantallas difiere de la salida impresa en varios puntos. Es efímera (es decir, una pantalla no es perma-
nente como las impresiones), puede estar orientada de manera más específica al usuario, está disponible en
un horario más flexible, no es portátil de la misma forma y algunas veces se puede modificar a través de la
interacción directa.
Además, hay que instruir a los usuarios en cuanto a las teclas que deben oprimir, los vínculos en los que de-
ben hacer clic o cómo desplazarse cuando quieren continuar leyendo pantallas adicionales, cuando desean saber
cómo terminar la pantalla y cuando quieren saber cómo interactuar con la pantalla (si es posible). El acceso de
los usuarios a las pantallas se puede controlar mediante una contraseña, mientras que la distribución de la salida
impresa se controla en base a otros medios.
Lineamientos para el diseño de pantallas
Cuatro lineamientos facilitan el diseño de pantallas:
1. Mantenga la pantalla simplificada.
2. Mantenga la presentación consistente.
3. Facilite el movimiento del usuario entre la salida que se muestra en la pantalla.
4. Cree una pantalla atractiva y agradable.
Al igual que con la salida impresa, las buenas pantallas no se crean en forma aislada. Los analistas de sistemas
necesitan la retroalimentación de los usuarios para diseñar pantallas que valgan la pena. Una vez aprobada por los
usuarios después de varios prototipos y refinaciones, se puede finalizar la distribución de la pantalla.
En la figura 11.7 se muestra la salida producida desde la pantalla de diseño. Cabe mencionar que no está
atestada de información, e incluso así proporciona un resumen básico del estado de envío. La pantalla orienta a
los usuarios en cuanto a lo que están viendo mediante el uso de un encabezado. Las instrucciones en la parte in-
Vendedor Pedido # Fecha del pedido Estado del pedido
Animals Unlimited 933401 09/05/2009 Se envió el 09/29
934567 09/11/2009 Se envió el 09/21
934613 09/13/2009 Se envió el 09/21
934691 09/14/2009 Se envió el 09/21
Bear Bizarre 933603 09/02/2009 Envío parcial
933668 09/08/2009 Programado para el 10/03
934552 09/18/2009 Programado para el 10/03
934683 09/18/2009 Se envió el 09/28
Cuddles Co. 933414 09/12/2009 Se envió el 09/18
933422 09/14/2009 Se envió el 09/21
934339 09/16/2009 Se envió el 09/26
934387 09/18/2009 Se envió el 09/21
934476 09/25/2009 Pedido pendiente
Stuffed Stuff 934341 09/14/2009 Se envió el 09/26
934591 09/18/2009 Envío parcial
934633 09/26/2009 Pedido pendiente
934664 09/29/2009 Envío parcial
Estado de pedidos de New Zoo
Oprima cualquier tecla para ver el resto de la lista; ESC para finalizar; ? para ayuda
Para obtener más detalle, coloque el cursor sobre el número de pedido y oprima Intro.
FIGURA 11.7
La pantalla de salida de New Zoo
está ordenada y orienta bien a los
usuarios.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 345
Pedido # Vendedor Fecha del pedido Estado del pedido
933603 Bear Bizarre 09/02/2008 Envío parcial
1001 Karhu Lane
Bern, Virginia 22024
Oprima cualquier tecla para ver el resto de la lista; ESC para finalizar; ? para ayuda
Unidades Paq. Descripción Precio Monto Estado detallado
12 Each Floppy Bears 20.00 240.00 Pedido pendiente vence el 10/15
6 Each Growlers 25.00 150.00 Pedido pendiente vence el 10/15
2 Each Special Edition 70.00 140.00 Se envió el 09/02
1 Box Celebrity Mix 150.00 150.00 Se envió el 09/02
12 Each Santa Bears 10.00 120.00 Pedido pendiente vence el 10/30
800.00
Contacto Saldo de la cuenta Clasificación de crédito Último pedido Enviado
Srita. Ursula Major 0.00 Excelente 08/21/2008 A tiempo
703-484-2327
FIGURA 11.8
Si los usuarios desean más detalles
relacionados con el estado de
envío, pueden pedir una pantalla
separada.
ferior de la pantalla proveen a los usuarios varias opciones, incluyendo continuar con la pantalla actual, terminar
con la pantalla, obtener ayuda u presentar más detalle. Esta pantalla provee contexto para los usuarios que tratan
de completar una tarea, como verificar el estado de un pedido.
Las pantallas de salida de una aplicación deben mostrar información de manera consistente, de una página
a otra. La figura 11.8 muestra la pantalla que se produce cuando el usuario coloca el cursor sobre el número de
pedido para un vendedor específico. La nueva pantalla presenta más detalles sobre Bear Bizarre. En el cuerpo
de la pantalla, el usuario puede ver el número de pedido del vendedor, la dirección completa, la fecha del pedido
y el estado. Además se proporciona un desglose detallado del envío y un estado detallado de cada parte del envío.
Se provee un nombre y número telefónico de contacto, junto con el saldo de la cuenta, la clasificación de cré-
dito y el historial de envíos. Cabe mencionar que la parte inferior de la pantalla aconseja al usuario sobre ciertas
opciones, incluir más detalles, finalizar la pantalla u obtener ayuda. Los usuarios reciben el control sobre lo que
podrían hacer después de ver la pantalla.
En vez de amontonar toda la información de un vendedor en una sola página, el analista ha hecho posible
que el usuario pueda ver la información sobre un vendedor específico en caso de que surja un problema o una
duda. Por ejemplo, si el resumen indica que se envió sólo una parte de un pedido, el usuario puede verificar más
detalles del mismo mediante una llamada a una pantalla detallada del vendedor, para después proceder con la
acción apropiada.
Uso de salida gráfica en el diseño de pantallas
La salida gráfica puede ser poderosa. Es mucho más fácil identificar una tendencia u observar un patrón cuando
se muestra la gráfica apropiada. La mayoría de las personas identifican mejor las diferencias en las gráficas que
en las tablas. Es importante colaborar con los usuarios para elegir el estilo correcto de gráfico para comunicar lo
que deseamos.
Al igual que con la presentación de la salida en formato tabular, la salida gráfica necesita ser precisa y fácil
de comprender y usar, si deseamos que sea efectiva para comunicar la información a los usuarios. Los encarga-
dos de tomar decisiones que usan las gráficas necesitan conocer las suposiciones (predisposiciones) bajo las que
se construyen, de manera que puedan realizar los ajustes o compensaciones necesarios.
Al diseñar la salida gráfica, el analista de sistemas y cualquier usuario involucrado en la creación de prototipos
de diseño deben determinar: 1) el propósito del gráfico, 2) el tipo de datos que hay que mostrar, 3) su audiencia y
4) los efectos sobre la audiencia de distintos tipos de salida gráfica. En el caso de un sistema de soporte de decisio-
nes, el propósito de una pantalla gráfica es apoyar cualquiera de las tres fases de solución de problemas a las que se
enfrenta un usuario: inteligencia, diseño o elección. En la figura 11.9 se muestra un ejemplo de DSS de planeación
de los elementos de la Policía Estatal de Nebraska. En este caso, los tiempos actuales de respuesta, los tiempos pro-
nosticados de respuesta y los requerimientos mínimos se grafican como barras con distintos sombreados.www.xlibros.com

346 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Tableros de control
Los encargados de tomar decisiones necesitan una salida que les ayude a tomar decisiones con efectividad y rapi-
dez. Es muy conveniente para los ejecutivos y demás personas encargadas de tomar decisiones que toda la infor-
mación necesaria para tomar las decisiones aparezca en pantallas frente a ellos. Cuando recibe un informe escrito,
el encargado de tomar decisiones preferiría que toda la información estuviera contenida dentro de ese informe, en
vez de tener que buscar información en otros lugares. El mismo principio se aplica al diseño de pantallas.
Un tablero de control, similar al tablero de un automóvil, tiene muchos medidores distintos. Cada medidor
puede mostrar una gráfica (algo así como la velocidad en millas o kilómetros por hora), un indicador de falla
(como un indicador que muestra que el sistema de freno automático no funciona) o incluso texto (como un odó-
metro que simplemente cuenta los kilómetros recorridos).
A un ejecutivo le puede parecer muy útil el tablero de control al tomar decisiones, pero sólo si su diseño es
apropiado. El tablero de control de la figura 11.10 muestra que se puede incluir una cantidad considerable de in-
formación en una sola pantalla.
FIGURA 11.10
Este tablero de control presenta
varios tipos de indicadores de
desempeño para ayudar a tomar
decisiones.
50
Actual
Tiempo
(en minutos)
Tiempo de respuesta promedio por área de tropa
Policía Estatal de Nebraska
Sede A B C D E Estado
MínimoPronosticado
Elementos en el área de tropa
45
40
35
30
25
20
15
10
5
0
FIGURA 11.9
Una pantalla de gráfico de barras
para inspeccionar el tiempo de
respuesta de la tropa en pantalla.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 347
Los tableros de control se enfocan en comunicar las mediciones al usuario. Un ejecutivo utiliza un tablero
de control para revisar las medidas de desempeño y tomar acción si la información en la pantalla lo requiere. He
aquí algunas reglas empíricas que puede utilizar para que el tablero de control que usted diseñe sea más atractivo
y efectivo:
1. Asegúrese que los datos tengan contexto. Si diseña una pantalla que indique que las ventas del mes pasado
fueron de $851,235, ¿qué significa eso? ¿Están las ventas por encima o por debajo del promedio?
2. Presente la información en forma apropiadamente sintética y precisa. Su pantalla se verá atestada si muestra
las ventas del mes pasado como $852,235.32, en vez de indicar en el título el uso de miles de dólares y
mostrar sólo 851.
3. Seleccione las medidas de desempeño apropiadas para la pantalla. Por ejemplo, trazar la diferencia entre las
ventas actuales y las esperadas en un gráfico de desviación es mucho más significativo que usar un gráfico
de línea para trazar las ventas actuales y esperadas.
4. Presente los datos en forma justa. Si hay predisposición en el tablero de control, dificultará las buenas
decisiones, en lugar de sustentarlas.
5. Seleccione el estilo correcto de gráfica para la pantalla. Es importante usar la gráfica adecuada. Aunque una
gráfica de pastel puede ser excelente para persuadir a alguien, tal vez no sea la mejor elección para que un
ejecutivo supervise el desempeño de las oficinas regionales, por ejemplo.
6. Use medios de visualización bien diseñados. Incluso si selecciona el mejor tipo de gráfica, de todas
formas necesitará dibujar, ajustar tamaño y color, y etiquetar la gráfica de manera significativa y
agradable.
7. Limite la variedad de tipos de elementos. Mantenga el menor número de estilos posibles de gráficos,
diagramas y tablas, de manera que la información se pueda comunicar con rapidez y precisión.
8. Resalte los datos importantes. Use colores brillantes y fuentes en negrita sólo para los datos importantes.
Puede resaltar las medidas clave de desempeño o las excepciones importantes que estén ocurriendo, pero no
ambas cosas. Seleccione qué desea enfatizar.
9. Ordene los datos en grupos representativos. Las medidas de desempeño casi siempre se asocian con otras
medidas de desempeño debido a los datos mostrados o el tipo de gráfico. Aprenda cómo agrupar los
elementos asociados.
10. Mantenga la pantalla actual ordenada. Evite las fotografías, los logotipos ornamentados o los temas que
puedan distraer a los usuarios de los datos.
11. Mantenga todo el tablero de control en una sola pantalla. Todas las medidas de desempeño deben estar en
la misma pantalla. Si se ve obligado a cambiar pantallas, un usuario no podrá ver dos medidas relevantes
a la vez.
12. Permita cierta flexibilidad. Si un ejecutivo desea un gráfico o diagrama distinto, considere reemplazarlo. Es
conveniente crear un prototipo del tablero de control y refinarlo con base en la retroalimentación del usuario.
A menudo los encargados de tomar decisiones saben más al tratarse de obtener la información correcta en la
forma más apropiada para su estilo de decisión.
Widgets y gadgets: modificación de la metáfora del escritorio
Los nuevos escritorios diseñados por los usuarios están relacionados con los tableros de control. Los diseñadores
de sistemas que desarrollan software para computadoras personales deberían estar al tanto de una tendencia para
animar a los usuarios a personalizar sus escritorios con widgets y gadgets. Estos elementos son pequeños progra-
mas, por lo general escritos en JavaScript y VBScript, que residen en una barra lateral unida a un navegador o
programa, o en una capa especial en el mismo escritorio.
Los Widgets (como los denomina Yahoo!), los Dashboard Widgets (como los denomina Apple) y los Gad-
gets (como los denominan Google y Microsoft) pueden ser cualquier tipo de programa que sea útil para alguien
que interactúe con una computadora. Algunos ejemplos de widgets populares de productividad son los relojes,
calculadoras, asistentes de sitios favoritos, traductores, motores de búsqueda, fácil acceso a las herramientas, pa-
neles de inicio rápido y las notas adhesivas.
Las cintas de cotizaciones de la bolsa, los informes meteorológicos y las fuentes RSS también son útiles
widgets. Los gadgets permiten a los usuarios rastrar paquetes y verificar horarios. El usuario puede poner tam-
bién juegos, podcasts de música y hobbies en su escritorio. Los widgets y gadgets poseen naturalezas duales, casi
paradójicas. Permiten a los usuarios contribuir al diseño de su propio escritorio, y los diseñadores observadores
pueden aprender mucho acerca de lo que prefieren los usuarios cuando estudian los escritorios diseñados por
usuarios. Pero los widgets y gadgets también pueden distraer a las personas de las tareas aceptadas por el sis-
tema. Los diseñadores necesitan trabajar con los usuarios para apoyarlos de manera que puedan lograr un equili-
brio. Una posibilidad es la de agregar medidas de desempeño específicas para cada usuario, así como widgets y
gadgets que sean útiles para los encargados de tomar decisiones.www.xlibros.com

348 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
DISEÑO DE UN SITIO WEB
Al diseñar un sitio Web podemos pedir prestados algunos de los principios de diseño provenientes del diseño
de pantallas. No obstante, cabe mencionar que la palabra clave aquí es sitio. Los primeros documentos que se
mostraron en Internet mediante el protocolo http se llamaban páginas iniciales, pero muy pronto se hizo evidente
que las empresas, universidades, gobiernos y personas no iban a mostrar sólo una página. El término sitio Web
reemplazó al de página de inicio para indicar que había que organizar, coordinar, diseñar, desarrollar y mantener
la colección de páginas en un proceso ordenado.
La impresión es un medio altamente controlable, por lo que el analista puede anticipar con precisión la apa-
riencia que tendrá la salida. Las pantallas GUI y basadas en carácter (CHUI, o interfaz de usuario basada en ca-
racteres) también están muy controladas. Sin embargo, la Web es un entorno con menor control para la salida.
Los distintos navegadores muestran las imágenes en forma diferente; la resolución de la pantalla provoca un
fuerte impacto sobre la apariencia visual de un sitio Web. Las resoluciones estándar son de 1024 768 píxeles o
de 1600 1200 píxeles. Esta cuestión se complica incluso más debido al uso de dispositivos portátiles, como los
teléfonos móviles con capacidades de navegación en Web. La complejidad aumenta cuando nos damos cuenta de
que cada persona puede configurar un navegador para usar distintas fuentes y tal vez deshabilite el uso de Java-
Script, cookies y demás elementos de programación. Los analistas y los usuarios se enfrentan a muchas decisio-
nes al desarrollar un sitio Web.
Además de los elementos generales de diseño que vimos antes en este capítulo, hay lineamientos específicos
apropiados para el diseño de sitios Web de calidad profesional. En la figura 11.11 se definen los términos Web.
Lineamientos generales para diseñar sitios Web
Hay muchas herramientas, así como ejemplos que pueden guiarlo al diseñar sitios Web.
USE HERRAMIENTAS PROFESIONALES Use un software conocido como editor Web; por ejemplo, Adobe
Dreamweaver o Microsoft Expression Web. Estas herramientas definitivamente valen lo que cuestan. Usted será
más creativo y terminará el sitio Web con mucha más rapidez que si trabajara directamente con HTML (lenguaje
de marcado de hipertexto).
O P O R T U N I D A D D E C O N S U L T O R Í A 1 1 . 4
¿Es tu trabajo aburrido?
“Quiero todo lo que pueda abarcar y entre más comprimida esté
la información, mejor. Olvide eso que escuchó acerca de la sobrecarga
de información; no es mi caso. Lo quiero todo y no en un montón de
informes bonitos de media hoja. Lo quiero todo junto, empaquetado
en una hoja que pueda llevar a una reunión en caso de que necesite
buscar algo. Y lo necesito cada semana”, solicita Stephen Links, vice-
presidente de una extensa empresa familiar de salchichas.
Durante una entrevista, Links ha estado interrogando con se-
veridad a Paul Plishka, quien forma parte del equipo de análisis de
sistemas que está ocupado con el diseño de un sistema de informa-
ción para Links Meats. Aunque Paul está renuente a lo que Links le
ha pedido, procede a diseñar un informe impreso que incluya todos
los elementos importantes que ha establecido el equipo durante la
fase de análisis.
Sin embargo, al entregar a Stephen el prototipo del nuevo re-
porte diseñado con base en sus especificaciones, parece haber un
cambio de opinión. Links dice en términos nada inciertos que no
puede encontrar lo que necesita.
“Eso se ve muy mal. Parecen recortes. Mi niño que está en
preescolar puede hacer mejores informes con sus crayones. Mira
nada más. Está todo revuelto. No puedo encontrar nada. ¿Dónde
está el resumen del número de artículos de res que se vendieron en
cada punto de venta?, ¿dónde el volumen total de artículos vendidos
para todos los puntos de venta?, ¿qué hay acerca de la información
en nuestra propia tienda del centro?”, dice Links mientras recorre el
informe.
Sin duda hay que rediseñar el informe. Diseñe un informe
(o informes) que se adapte mejor a las necesidades de Stephen
Links. ¿Qué método puede adoptar el analista para sugerir más in-
formes con un formato menos atestado? Comente sobre la dificul-
tad de implementar sugerencias de los usuarios que vayan en contra
de su capacitación sobre diseño. ¿Cuáles son los conflictos involu-
crados (en relación con la sobrecarga de información) en la genera-
ción de numerosos informes, en comparación con la generación de
un informe extenso que contenga toda la información que desea
Stephen? Idee una heurística para la visualización de la información
en un solo informe, en comparación con la generación de varios.
Considere defender una solución basada en Web o en tablero de
control que permita hipervínculos a toda la información que desea
Stephen. ¿Qué tan viable sería eso?www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 349
Término Web Significado
Ajax
CSS
DHTML
GIF
Java
JPEG
HTML
http://
complementos
o plug-ins
URL
VB .NET
Webmaster
WMP
Un método que utiliza JavaScript y XML para modificar páginas Web en forma dinámica, sin mostrar una
nueva página, mediante la obtención de pequeñas cantidades de datos del servidor.
Hojas de estilo en cascada, un conjunto de estilos que controlan el formato de una página Web. Los estilos CSS se pueden
almacenar en un archivo y usar para dar formato a varias páginas Web, o se pueden definir dentro de una página Web.
HTML dinámico, una forma de combinar JavaScript y tal vez las hojas de estilo en cascada para hacer que
la página Web cambie con base en las acciones del usuario.
Formato de intercambio de gráficos, un formato popular de imágenes comprimidas que se adapta muy bien al material gráfico.
Un lenguaje orientado a objetos que permite ejecutar aplicaciones dinámicas en Internet. Los que no son
programadores pueden usar paquetes de software tales como Visual Café para Java de Symantec.
Grupo unido de expertos en fotografía, el acrónimo para un popular formato de imágenes comprimidas que se
adapta muy bien a las fotografías; el diseñador puede ajustar la calidad de estas fotografías.
Lenguaje de marcado de hipertexto, el lenguaje detrás de la apariencia de los documentos en Web. En realidad es
un conjunto de convenciones que marcan las porciones de un documento para indicarle al navegador qué formato
distintivo debe aparecer en cada porción de una página.
Protocolo de transferencia de hipertexto, se utiliza para mover páginas Web entre distintas computadoras; por
ejemplo, desde un sitio Web en una computadora que esté en otro país, hasta su computadora personal.
PHP Un lenguaje de programación de código fuente abierto, que a menudo se utiliza con MySQL, un sistema de administración
de bases de datos.
Software adicional (a menudo desarrollado por un tercero) que se puede utilizar con otro programa; por ejemplo,
Real Player de RealNetworks o Macromedia Flash se utilizan como complementos en los navegadores Web para
reproducir audio o video de flujo continuo y ver animaciones basadas en vectores.
Localizador uniforme de recursos, la dirección de un documento o programa en Internet. Las extensiones conocidas
son .com para comercios, .edu para instituciones educativas, .gov o .gob para instituciones gubernamentales, .org
para organizaciones, etcétera.
Visual Basic .NET, un entorno de programación de Microsoft.
La persona responsable de mantener el sitio Web.
Windows media photo, una alternativa a JPEG desarrollada por Microsoft.
FAQ Preguntas frecuentes. Con frecuencia los sitios Web tienen una página dedicada a estas preguntas frecuentes, para
que la fuerza de ventas de la empresa o el equipo de soporte técnico no se vean inundados con las mismas
preguntas una y otra vez; además los usuarios pueden tener acceso a las respuestas las 24 horas del día.
FTP Protocolo de transferencia de archivos, en la actualidad es la forma más común de mover archivos entre distintos sistemas
computarizados.
FIGURA 11.11
Términos del vocabulario Web.
ESTUDIE OTROS SITIOS WEB Analice los sitios Web que usted y otros usuarios piensen que son interesantes.
Analice los elementos de diseño que utilicen y vea cómo funcionan; después trate de emular lo que ve mediante
la creación de páginas de prototipo (no es ético ni legal cortar y pegar imágenes o código, pero de todas formas
puede aprender algo de los otros sitios).
Firefox, que forma parte del movimiento de software de código fuente abierto, es un útil navegador para es-
tudiar otros sitios Web. Tiene varias extensiones creadas por terceros desarrolladores, las cuales están disponibles
como descargas gratuitas. Ejecute Firefox, haga clic en “Herramientas/Complementos” y después en “Examinar
todos los complementos”. Hay páginas de complementos y extensiones; una, llamada Web Developer, es muy
útil para los diseñadores y webmasters, ya que permite al analista delinear tablas y estilos, además de ver Java-
Script y cookies; provee información además de muchos otros útiles elementos a escoger. Palette Grabber es otra
extensión que permite a los desarrolladores Web ver una pantalla de códigos de color con sólo elegir un color
en un sitio Web. También hay herramientas para trabajar con XML. La figura 11.12 es un ejemplo de la barra de
herramientas Web Developer que se utiliza para resaltar las celdas de las tablas. Observe el borde rojo alrededor
de cada celda individual.www.xlibros.com

350 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
USE LOS RECURSOS QUE OFRECE LA WEB Analice los sitios Web que ofrecen sugerencias sobre diseño. Uno de
ellos es useit.com.
EXAMINE LOS SITIOS WEB DE DISEÑADORES PROFESIONALES Mientras analiza páginas diseñadas por
profesionales pregúntese: “¿Qué es lo que funciona? ¿Qué no funciona? ¿En qué formas pueden los usuarios
interactuar con el sitio?” Por ejemplo, ¿tiene el sitio vínculos activos a direcciones de correo electrónico,
formularios interactivos que se pueden llenar, encuestas para el consumidor, juegos, cuestionarios, salas de chat,
etcétera? ¿Qué hay sobre los esquemas de color y las metáforas omnipresentes?
USE LAS HERRAMIENTAS QUE APRENDIÓ La figura 11.13 provee un formulario que algunos diseñadores Web
han usado con éxito para evaluar las páginas Web en forma sistemática. Tal vez quiera usar este formulario para
FIGURA 11.12
Un desarrollador Web puede
delinear las celdas de las tablas al
diseñar una página Web, como se
muestra en este ejemplo.
Crítica de sitio Web
Nombre del analista
URL visitadoHora de visita:
Fecha de visita:
DISEÑO
Necesita
mejorar Excelente
Apariencia en general
Uso de gráficos
Uso de color
Uso de sonido/video (multimedia)
Uso de nueva tecnología y productos
Contenido
Capacidad de navegación
Administración del sitio y comunicaciones
COMENTARIOS
CONTENIDO E INTERACTIVIDAD
PUNTUACIÓN
1
1
1
1
1
1
1
1
5
5
5
5
5
4
4
4
4
4
3
3
3
3
3
2
2
2
2
2
5
5
5
4
4
4
3
3
3
2
2
2
/40
FIGURA 11.13
Un formulario de evaluación de
sitios Web.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 351
que le ayude a comparar y contrastar todos los sitios Web que visitará a medida que aprende sobre el diseño de
páginas Web.
CONSULTE ALGUNOS LIBROS Algo que puede aumentar su experiencia en este nuevo campo es leer sobre el
diseño Web. Algunos buenos libros sobre diseño Web son:
Eckerson, W. W. Performance Dashboards: Measuring, Monitoring, and Managing Your Business. Nueva York:
John Wiley & Sons, Inc., 2005.
Few, S. Information Dashboard Design: The Effective Visual Communication of Data. Sebastopol, CA: O’Reilly
Media, Incorporated, 2006.
Flanders, V. y D. Peters. Son of Web Pages That Suck: Learn Good Design by Looking at Bad Design. Alameda,
CA: Sybex, 2002.
McNeil, P. The Web Designer’s Idea Book: The Ultimate Guide to Themes, Trends & Styles in Website Design.
Nueva York: F+W Media, 2008.
A T R A C T I V O D E L A M A C
Hay muchas metodologías para crear sitios Web. Los codificadores desean el mayor grado de control posible sobre el
código HTML, pero muchos diseñadores no están tan interesados en dominarlo. Los buenos diseñadores desean poder
incluir muchos elementos distintos tanto en gráficos como en texto, girar y mejorar imágenes, darles formato en diseños
cuidadosamente elaborados y hacer que tengan la misma apariencia en cualquier navegador y en cualquier resolución.
Hay muchos paquetes WYSIWYG disponibles que permiten a los diseñadores hacer esto, tanto en una Mac como en
una PC. Algunos de estos paquetes funcionan bien; otros no.
Softpress Systems, los desarrolladores de Freeway Pro, han creado software de diseño Web con un enfoque dife-
rente. A diferencia de otros paquetes, Freeway Pro no crea código mientras el diseñador trabaja, sino hasta que el dise-
ñador está satisfecho con su diseño. De esta manera, el código es en extremo eficiente. También es una herramienta muy
útil para la creación de prototipos. Freeway Pro supone que cuando cambien los estándares, las actualizaciones para el
software permitirán a los diseñadores Web volver a publicar todo el sitio utilizando el estándar actualizado.
FIGURA 11.MAC
Freeway Pro de Softpress Systems ofrece un enfoque único para los diseñadores de sitios Web.www.xlibros.com

352 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
ANALICE TAMBIÉN MALOS EJEMPLOS DE PÁGINAS WEB Elabore críticas de páginas Web mal diseñadas y
recuerde evitar esos errores. Examine el sitio Web en www.webpagesthatsuck.com. A pesar de su nombre
“contracultural”, es un maravilloso sitio que provee vínculos a muchos sitios mal diseñados y resalta los errores
que cometieron sus diseñadores.
CREE SUS PROPIAS PLANTILLAS Si adopta una página con apariencia estándar para la mayoría de las páginas que
vaya a crear, podrá tener el sitio Web en funcionamiento rápidamente, con una apariencia buena y consistente.
Se pueden crear sitios Web mediante el uso de hojas de estilo en cascada (CSS), con lo cual el diseñador puede
especificar sólo una vez el color, tamaño y tipo de fuente, además de muchos otros atributos. Estos atributos se
almacenan en un archivo de hoja de estilo y después se aplican a muchas páginas Web. Si un diseñador cambia
una especificación en el archivo de hoja de estilo, se actualizarán todas las páginas Web que utilizan esa hoja de
estilo para reflejar el nuevo estilo.
USE COMPLEMENTOS, AUDIO Y VIDEO CON MEDIDA Es maravilloso tener las nuevas características que poseen
las páginas profesionales, pero debemos recordar que todos los que ven nuestro sitio no necesitan tener todos los
nuevos complementos. No ahuyente a los visitantes de su página.
PLANIFIQUE Los buenos sitios Web están cuidadosamente planificados. Ponga atención a lo siguiente:
1. Estructura.
2. Contenido.
3. Texto.
4. Gráficos.
5. Estilo de presentación.
6. Navegación.
7. Promoción.
Estructura Planificar la estructura de un sitio Web es uno de los pasos más importantes para desarrollar un sitio Web
profesional. Piense en sus metas y objetivos. Cada página de la estructura Web general debe tener un mensaje o
Logotipo del sitio Web Artículo de portadaImagen jpeg
Suscripción
de video
Vínculos rápidos Artículos principales Salas de chatAnuncios Vínculo de contacto por email
Fuentes RSS
Anuncios de pancarta
Vínculos a
sub-Webs
Motor de búsqueda
FIGURA 11.14
El sitio Web de DinoTech utiliza al máximo los vínculos, fuentes RSS,
suscripciones de video y anuncios de pancarta.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 353
FIGURA 11.15
Podemos evaluar los vínculos
rotos en un sitio Web mediante el
uso de un paquete como Microsoft
Visio.
alguna otra información relacionada. Algunas veces es conveniente examinar sitios profesionales para analizarlos
en cuanto a su contenido y características. En la figura 11.14 se muestra una pantalla del sitio Web DinoTech. El
propósito del sitio y el medio Web funcionan bien en conjunto. Observe que hay mucho énfasis en apoyar a los
usuarios en el sitio. Hay texto, gráficos, imágenes JPEG e iconos. Además hay muchos tipos de vínculos: a fuentes
RSS, video, sub-Webs, salas de chat, un motor de búsqueda y muchas otras características.
Para ayudar a planear y mantener una estructura sólida, un webmaster puede aprovechar las diversas he-
rramientas para creación de diagramas y mapas de sitios Web disponibles. Muchos paquetes de software, inclu-
yendo Microsoft Visio, tienen opciones de diagramas Web integradas en el software. Además de ser útiles para
el desarrollo, estas herramientas se vuelven incluso más importantes al dar mantenimiento al sitio. Dada la natu-
raleza dinámica de la Web, los sitios vinculados a su sitio podrían moverse en cualquier momento y usted o su
webmaster tendrían que actualizar los vínculos.
En la figura 11.15 se muestra un mapa de una sección del sitio Web de los autores en la ventana de Micro-
soft Visio. En este ejemplo exploramos el sitio Web en todos los niveles existentes. Observe los vínculos a pági-
nas de HTML, documentos, imágenes (archivos GIF o JPEG) y elementos “mail-to” (una forma de enviar correo
electrónico a una persona designada). Los vínculos pueden ser internos o externos. Si un vínculo está roto, apa-
rece una X de color rojo y el analista puede investigar más sobre ello. Este archivo de Visio se puede imprimir en
secciones para publicarlo en la pared y obtener una imagen general del sitio Web.
Contenido Provea algo importante a los usuarios del sitio Web. Las animaciones, películas y sonidos
emocionantes y divertidos, pero debe incluir el contenido apropiado para que el usuario siga interesado. Ofrezca
algún consejo oportuno, información importante, una oferta gratuita o cualquier actividad que pueda proveer, que
sea interactiva y haga que los usuarios pasen del modo de exploración al modo interactivo.
La pegajosidad es una cualidad que debe poseer un sitio Web. Si un usuario permanece en su sitio durante
un extenso periodo de tiempo, su sitio tiene un alto grado de pegajosidad. Ésta es la razón por la que un comer-
ciante incluye muchos elementos de interés en un sitio. Por ejemplo, un comerciante de vinos puede poner lec-
ciones sobre cómo descorchar una botella, probar el vino o elegir una copa adecuada.
Use una metáfora o imágenes que provean una metáfora para su sitio. Puede usar un tema, como un esca-
parate, con páginas adicionales que tengan varias metáforas relacionadas con el escaparate, como una tienda de
productos gourmet. Evite el uso excesivo de caricaturas y no sea repetitivo.
Todo sitio Web debe incluir una página FAQ (preguntas frecuentes). A menudo estas preguntas se crean con
base en las experiencias de los usuarios y el personal de soporte técnico, quienes identifican los temas de preocu-
pación continua. El ochenta por ciento de las preguntas entra a la categoría FAQ. Al tener las respuestas disponi-
bles las 24 horas del día, ahorrará el valioso tiempo de sus empleados y los usuarios. Las páginas FAQ también
demuestran a los usuarios de su sitio que está coordinado con ellos y tiene una buena idea de lo que les gustaría
conocer.www.xlibros.com

354 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
En la Web, el software COTS tiene otro significado: un sitio puede aprovechar el software previamente es-
crito. Algunos ejemplos son los motores de búsqueda (como Google), el software para mapas (como MapQuest),
la información sobre el clima y los cintillos de noticias y de la bolsa de valores. Los diseñadores de sitios Web
aprecian estos paquetes debido a que pueden incrementar la funcionalidad del sitio, y las características adiciona-
les alientan a los usuarios a marcar los sitios Web de sus clientes como sitios favoritos, ya que proveen un conte-
nido adicional valioso.
Texto Recuerde que el texto también es importante. Cada página Web debe tener un título. Coloque las palabras
significativas en el primer enunciado que aparece en su página Web. Deje que las personas sepan que están
navegando en el sitio Web correcto. La escritura clara es especialmente importante.
Gráficos La siguiente lista provee los detalles sobre la creación de gráficos efectivos para sitios Web:
1. Use uno de los formatos de imagen que se utilizan con más frecuencia, JPEG o GIF. Las imágenes JPEG
son mejores para las fotografías y las imágenes GIF son mejores para las ilustraciones. Las imágenes GIF
están limitadas a 256 colores, pero pueden incluir un fondo transparente, píxeles que permiten mostrar el
fondo a través de la imagen GIF. Las imágenes GIF también pueden ser entrelazadas, lo cual significa que
el navegador Web mostrará la imagen en etapas sucesivas, presentando una imagen más clara en cada
etapa.
2. Mantenga el fondo simple y asegúrese de que los usuarios puedan leer el texto con claridad. Al utilizar un
patrón de fondo, asegúrese de poder leer el texto encima del fondo claramente.
3. Cree unos cuantos gráficos con apariencia profesional para usarlos en sus páginas.
4. Mantenga las imágenes gráficas pequeñas y reutilice las viñetas o botones de navegación, como
RETROCEDER, ARRIBA, EMAIL y SIGUIENTE. Estas imágenes se almacenan en una caché, un área en
el disco duro de la computadora que está navegando por el sitio Web. Una vez recibida una imagen, se
tomará de la caché cada vez que se vuelva a utilizar. El uso de imágenes en caché aumenta la velocidad con
la que un navegador puede cargar una página Web.
5. Incluya texto en lo que se denomina atributo de texto para las imágenes y los puntos activos de imágenes. El
texto aparece cuando el usuario desplaza el ratón encima de la imagen. Un atributo alt provee texto para los
lectores de pantalla y es esencial para ofrecer el soporte de accesibilidad Web para los visitantes con
discapacidad visual.
6. Examine su sitio Web en varias pantallas y resoluciones de pantalla. Las escenas y el texto que se ven bien
en una pantalla de video de alta tecnología tal vez no se vean bien en otras pantallas de menor calidad.
Estilo de presentación La siguiente lista muestra detalles adicionales sobre cómo diseñar pantallas de entrada
atractivas.
1. Ofrezca una pantalla de entrada (también conocida como página de inicio) que introduzca al visitante al
sitio Web. La página se debe diseñar de manera que se cargue rápidamente. Una buena regla práctica es
diseñar una página que se cargue en 14 segundos (considere que la conexión del visitante de su sitio Web
podría ser más lenta). Esta pantalla de entrada debe ser de 100 kilobytes o menos, incluyendo todos los
gráficos.
La página de entrada debe contener varias opciones, algo similar a un menú. Una forma fácil de
lograr esto es diseñar un conjunto de vínculos o botones y colocarlos en el lado izquierdo o en la parte
superior de la pantalla. Estos vínculos se pueden enlazar a otras páginas en el mismo sitio Web o a
distintos sitios Web. Podemos incluir un menú de texto especializado con una fuente de menor tamaño en
la parte superior o inferior de la página. En la figura 11.16 se muestra un ejemplo de una página de
entrada que contiene una imagen extensa y algo de contenido, pero que permite al visitante navegar hacia
cualquier otra parte del sitio. Esta página se construyó con software que permite a los diseñadores ver el
código de HTML (en la parte inferior de la pantalla) al mismo tiempo que la apariencia que tendrá la
página en un navegador Web.
2. Mantenga el número de gráficos a un mínimo razonable. Se requiere un tiempo de descarga adicional para
transferir un sitio con muchos gráficos.
3. Use fuentes grandes y coloridas para los encabezados.
4. Use imágenes y botones interesantes para los vínculos. A un grupo de imágenes que se combinan en una
sola imagen se le denomina mapa de imágenes, el cual contiene varios puntos activos que actúan como
vínculos hacia otras páginas.
5. Use hojas de estilo en cascada (CSS) para controlar el formato y la distribución de la página Web. Las hojas
CSS separan el contenido (el texto y las imágenes) de la apariencia (la presentación). Por lo general, las
hojas de estilo en cascada se almacenan en un archivo externo a la página Web; además, una hoja de estilo
puede controlar el formato de muchas páginas. Una ventaja de usar las hojas de estilo externas es hacer unawww.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 355
modificación en la hoja de estilo; por ejemplo, al cambiar el color del texto en negritas cambiará el formato
de todas las páginas Web que utilizan esa hoja de estilo. También podemos usar hojas de estilo en cascada en
una sola página Web y cualquier estilo duplicado invalidará al de una hoja de estilo externa, en caso de que
se utilice alguna. Esto permite al diseñador variar la apariencia visual estándar de un sitio Web, tal vez para
una página Web de “venta especial” o alguna otra excepción. Es posible agregar estilos a elementos
individuales en una página Web para anular cualquier otra hoja de estilo.
6. Use divisiones y hojas en cascada o tablas para mejorar la distribución de una página Web. Las tablas son
fáciles de usar y proveen una distribución adecuada; sin embargo, no son muy apropiadas para los visitantes
discapacitados. El software de lectura de pantalla lee a través de la página, no necesariamente en la columna
de una tabla. Para controlar la distribución en pantalla, las divisiones proveen bloques de texto en la página
Web. Cada bloque se puede definir con una posición a partir de la esquina superior izquierda de la pantalla o
de un bloque más grande; además puede tener una anchura y una altura, así como un estilo de borde y un
color de fondo. Las divisiones eliminan la necesidad de colocar tablas dentro de otras tablas y simplifican el
diseño; el software de lectura de pantalla leerá todo el texto en la división para que los visitantes con
discapacidad visual puedan acceder al sitio.
7. Use la misma imagen gráfica en varias páginas Web. Mejorará la consistencia y las páginas cargarán con
más rapidez debido a que la computadora almacena la imagen en una caché y no tiene que volver a
cargarla.
8. Use JavaScript para mejorar la distribución de la página Web al hacer que las imágenes cambien cuando se
coloque el ratón encima de ellas o que se expandan los menús, por ejemplo. Podemos usar JavaScript para
volver a dar formato a la página Web con base en la altura y anchura de la pantalla. Si el sitio Web es
multinacional, JavaScript puede detectar el lenguaje que se esté usando (una configuración del navegador) y
redirigir al espectador a una versión de su página Web en otro idioma.
9. Evite el uso excesivo de las animaciones, sonidos y otros elementos relacionados.
Navegación ¿Es divertido para usted seguir los vínculos en la Web? La respuesta más probable es que depende
de ciertos factores. Cuando descubrimos un sitio Web que se carga fácilmente, tiene vínculos representativos
y nos permite regresar con facilidad a los lugares que queremos, entonces es probable que pensemos que es
divertido. La diversión no es sólo jugar; también puede ser una parte importante del trabajo. La investigación
reciente demuestra que la diversión puede tener un poderoso efecto en la efectividad de la capacitación por
computadora.
Por otro lado, si no puede decidir en cuál botón o punto activo de una imagen hacer clic y tiene miedo de
elegir el incorrecto porque podría terminar en la página equivocada que tarda mucho tiempo en cargar, entonces
la navegación es más desagradable que divertida. Un ejemplo es visitar la página de una compañía de software
para buscar información sobre las características de la versión más reciente de un producto. Usted tiene las op-
ciones tales como productos, descarga, FAQ y soporte técnico. ¿Qué botón lo llevará a las respuestas que busca?
FIGURA 11.16
Mediante el uso de un editor de
HTML (Visual Page en este
ejemplo), el diseñador de un sitio
Web puede ver la apariencia que
tendrá una página en el navegador
y el código de HTML (vea la parte
inferior de la pantalla) al mismo
tiempo.www.xlibros.com

356 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Lo que es más importante, observe la regla de los tres clics. Los usuarios deben ser capaces de moverse
desde la página en la que se encuentran hacia la página que contiene la información que desean en tres clics del
botón del ratón.
Promoción Promueva su sitio. No suponga que los motores de búsqueda lo encontrarán de inmediato. Envíe su
sitio cada dos o tres meses a varios motores de búsqueda. Incluya palabras clave, conocidas como metaetiquetas,
que los motores de búsqueda utilizarán para vincular las peticiones de búsqueda a su sitio. En la página Web
searchenginewatch.com/showPage.html?page=2167931 encontrará información general sobre las metaetiquetas.
En www.siteup.com/meta.html podrá descargar un software generador de metaetiquetas gratuito y encontrará un
creador de metaetiquetas en vancouver-webpages.com/META/mk-metas.html. También puede comprar software
para facilitar este proceso. Si trata de usar correo electrónico para promover su sitio, otros lo considerarán correo
basura o spam.
Anime a sus lectores a marcar su sitio Web como sitio favorito. Si usted coloca vínculos y les sugiere que
vayan a sitios Web afiliados que tengan “la mejor página de reseñas de películas en el mundo” o el sitio Web
para “obtener música gratuita”, no de por sentado que regresarán a su sitio en un futuro cercano. La manera de
animar a sus visitantes a que vuelvan a visitar su sitio es que lo marquen como favorito (a los marcadores se les
llama “favoritos” en Microsoft Internet Explorer). Puede agregar el vínculo Haga clic aquí para marcar esta
página a su página Web para automatizar el proceso. Tal vez también quiera diseñar un “favicon” o icono favo-
rito, para que los usuarios puedan identificar su sitio en sus listas de favoritos.
Mantenimiento de los sitios Web
Como desarrollador Web tal vez también le pidan que mantenga y actualice sitios Web en forma continua. Éste
es un servicio que usted puede proveer y el pago se puede acordar durante las primeras negociaciones del con-
trato del proyecto y su presupuesto. En la actualidad podemos dar por hecho que hay muchas características en
los sitios Web corporativos que son estables y, por ende, no requieren de mucha actualización. Sin embargo,
el panorama es distinto para los sitios de comercio electrónico, donde hay que actualizar el contenido según la
temporada. Los elementos a mostrar en la página principal cambian, al igual que las tendencias, los descuentos
O P O R T U N I D A D D E C O N S U L T O R Í A 1 1 . 5
Un día en el campo
“La cosa es que soy impaciente”, dice Seymour Fields, propie-
tario de una cadena de 15 exitosas florerías/mercados florales en
interiores de nombre Fields, que se encuentran en tres ciudades
del Medio Oeste. “¿Ve esto aquí?”, golpetea la pantalla de su PC
con fastidio. “Llevamos la nómina y toda la contabilidad con estas
cosas, pero no les doy el uso que debería darles. En realidad me
siento un poco culpable sobre ello. ¿Ve?”, dice mientras hace una
raya en la pantalla con su dedo. “Incluso tiene polvo. Pero soy
una persona práctica. Si está aquí ocupando espacio, quiero usarla.
U olerla, o por lo menos disfrutar al verla, como las flores, ¿no
cree usted? O sacarla de raíz. Es lo que digo. La única vez que
traté de hacer algo con ella fue un verdadero desastre. Bueno,
mire, le puedo mostrar si es que todavía recuerdo cómo hacerlo”.
Seymour procede a tratar de ejecutar un programa, pero no puede
hacer que funcione.
Clay Potts es un analista de sistemas que ha estado trabajando
en un proyecto de sistemas para toda la cadena Fields. Parte de la
propuesta original fue proveer a Seymour y sus vicepresidentes un
sistema de soporte de decisiones en grupo que les ayudara a idear
una estrategia para determinar qué mercados europeos visitar para
establecer contratos de compra de flores frescas, a qué puntos de
venta enviar ciertos tipos específicos de flores y cuánta mercancía
general (como macetas, floreros, tarjetas y chucherías) almacenar
en cada punto de venta.
Seymour continúa: “Le puedo decir qué es lo que no nos gustó
sobre el programa con el que trabajé. Había que pasar por demasia-
das capas, demasiado follaje o como se llame. Incluso con una
pantalla frente a mí, era como cambiar páginas en un informe
grueso. ¿Cómo se le dice a eso?”.
“¿Menús?”, sugiere Potts para tratar de ayudar. “El punto
principal es que no le gustó tener que pasar por mucha información
para llegar a la pantalla que necesitaba”.
Seymour Fields mira felizmente a Potts y dice: “Acertaste.
Quiero ver más campos en cada pantalla”.
¿Cómo debería diseñar Potts la salida de pantalla de manera
que Fields y su grupo puedan obtener lo que desean en cada pan-
talla, cumpliendo a la vez con los lineamientos para el buen diseño
de pantallas? Recuerde que los miembros del grupo están ocupa-
dos y utilizan la computadora con poca frecuencia. Diseñe una
página con hipervínculos que trabaje bien en un DSS para los vi-
cepresidentes. ¿Qué debemos incluir en la primera pantalla y qué
deberíamos almacenar en hipervínculos? Haga una lista de los
elementos para cada opción y explique en un párrafo por qué de-
cidió sobre esta estrategia.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 357
y las características interactivas. Los sistemas de administración de contenido (CMS) son potentes herramientas
de software que pueden permitir al analista desarrollar y dar mantenimiento a sitios Web y demás aplicaciones
en línea. Joomla! es un CMS cada vez más popular, que podrá bajar de www.joomla.org/about-joomla.html. Está
basado en PHP y MySQL. A diferencia de muchos CMS propietarios, que son costosos y no están disponibles
en muchas partes, Joomla! es una solución de código fuente abierto disponible en forma gratuita para cualquier
desarrollador.
Creación de blogs (Weblogs)
Los usuarios corporativos escriben blogs, también conocidos como Weblogs, para la comunicación tanto interna
como externa. Los blogs son informales y personales; a menudo invitan a los comentarios y la retroalimentación.
Son muy fáciles de crear y actualizar; están diseñados para cambiar a diario. Las empresas usan blogs para publi-
cidad y para crear redes sociales para sus consumidores, clientes y distribuidores en torno a sus productos, con lo
cual crean confianza y relaciones con los clientes.
Los blogs corporativos se supervisan con base en un sentido de responsabilidad por los participantes. Los
lineamientos, las políticas y las leyes que conforman las prácticas de supervisión incluyen valores culturales,
éticos y legales compartidos, tales como respetar a los demás empleados y clientes, no publicar información deli-
cada o secreta sobre la empresa ni cualquier cosa protegida por copyright (sin permiso); también hay que excluir
todo lo que se incite el odio, que sea ofensivo o que viole la privacidad de otros.
Incluso con todos los lineamientos anteriores, de todas formas debe asegurarse de que los mensajes publica-
dos en los blogs se expresen en lenguaje natural y no en términos legales. La entrada más reciente debe aparecer
al principio del blog y debe contener los siguientes elementos:
1. El permalink, o vínculo permanente, específico para cada mensaje publicado en el blog. El permalink nunca
debe cambiar.
2. El encabezado o título del mensaje.
3. El vínculo primario, que conecta al lector con el tema en discusión.
4. Un resumen opcional, que a menudo aparece después del vínculo.
5. El texto o comentario del blog.
6. Una imagen opcional.
7. Una cita en bloque, que contiene citas o demás material de otras fuentes para contribuir a la discusión
(a menudo con sangría o en una fuente distinta, para diferenciarla del texto principal).
8. Vínculos para los comentarios de otras personas.
9. Otras características del software de blog, como un calendario, un formulario de búsqueda y demás
características universales.
PRODUCCIÓN DE LA SALIDA Y XML
La producción de la salida varía dependiendo de la plataforma utilizada para producirla. Hay muchas formas
distintas de crear salida, que varían desde el software simple de bases de datos como Microsoft Access, hasta
programas tales como SAS, Crystal Reports y los archivos PDF de Adobe Acrobat.
En el capítulo 8 vimos el XML. Una de las ventajas de usar XML es que el documento de XML se puede
transformar en distintos tipos de medios de salida. Para ello se utilizan las hojas de estilo en cascada (CSS) o
las transformaciones de lenguaje de estilo extensible (XSLT). Estos métodos refuerzan la idea de que los datos se
deben definir una vez y se pueden usar muchas veces en distintos formatos.
Las hojas de estilo en cascada son una manera sencilla de transformar un documento de XML. La hoja de
estilo provee una serie de estilos, como la familia de la fuente, el tamaño, el color, el borde, etcétera, que se vincu-
lan con los elementos del documento de XML. Estos estilos pueden variar para distintos medios: una pantalla,
salida impresa o un dispositivo portátil. El software de transformación detecta el tipo de dispositivo y aplica los
estilos correctos para controlar la salida.
Por ejemplo, un estilo utilizado para una pantalla de panel plano podría utilizar una paleta con muchos co-
lores y una fuente sans-serif, que es más fácil de leer en una pantalla. Se puede usar un estilo diferente que con-
tenga una fuente serif en color negro o gris para definir un informe impreso para los mismos datos. Podríamos
usar un tamaño de fuente más pequeño para un dispositivo portátil o un teléfono móvil.
La desventaja de usar las hojas de estilo en cascada es que no permiten al analista manipular los datos, como
reordenar los elementos o clasificarlos, y sólo se puede agregar una cantidad limitada de texto de identificación,
como las leyendas. Se utilizan básicamente para el formato.
Las transformaciones de lenguaje de estilo extensible (XSLT) son un medio más potente para transformar un
documento de XML, ya que permiten al analista seleccionar los elementos e insertarlos en una página Web o en
otro medio de salida. La figura 11.17 muestra el proceso de transformación. XSLT no es un lenguaje de progra-www.xlibros.com

358 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
mación, pero utiliza una serie de instrucciones para definir qué elementos se deben usar como salida, la secuencia
de orden, la selección de datos, etcétera. En la figura 11.18 se muestra un ejemplo de transformación de XML. El
XML se muestra a la izquierda y el resultado de la transformación se muestra a la derecha. Cabe mencionar que
sólo se incluyen en la salida los datos entre las etiquetas (los símbolos menor que [<] y mayor que [>]).
Ajax
Hay otra técnica conocida como Ajax que utiliza JavaScript y XML para obtener pequeñas cantidades de datos
(ya sea en texto simple o XML) de un servidor sin dejar la página Web. Ésta es una gran ventaja, ya que elimina
la necesidad de cargar toda la página Web completa. Funciona al permitir que la página Web se vuelva a dar for-
mato a sí misma con base en las opciones introducidas por el usuario. Como Ajax está también relacionado con
la entrada de los usuarios, en el capítulo 12 podrá consultar detalles adicionales.
En esta sección hablaremos sobre Ajax debido a que tiene implicaciones importantes también en el aspecto
de la salida. El analista y el diseñador deben determinar cuándo se deben agregar o modificar los datos en una
página Web; también deben identificar las condiciones que producen la modificación. El orden en que se hacen
las preguntas también es importante en este diseño.
En la figura 11.19 se muestra un ejemplo de una página Web que utiliza Ajax, la cual demuestra que Ajax
hace que sea posible mostrar mucho menos datos en una página, con lo cual la salida se vuelve menos desorde-
nada y confusa. En este ejemplo, el usuario introdujo una de las cuatro formas disponibles para reducir la bús-
queda y ver una lista de los clientes actuales. Las opciones que el usuario tenía disponibles eran: 1) introducir los
primeros tres dígitos de un código postal, 2) introducir un código de área telefónica, 3) seleccionar el estado o
4) seleccionar un país. Tal vez el usuario no conozca el código postal o de área y por lo tanto tenga que buscar
por estado o país, por lo que las opciones son muy útiles.
Después de introducir una de las opciones de ubicación, en este caso los primeros tres dígitos del código
postal, el usuario hizo clic en el botón Get Customers (obtener clientes). El valor del código postal se envía al
servidor junto con los datos que indican que era un código postal. Después el servidor busca todos los registros
de los clientes para la ubicación seleccionada, crea un documento de XML y lo envía a la misma página Web.
Al diseñar la salida, el analista de sistemas tiene muchas opciones relacionadas con la forma de mostrar es-
tos datos en la página Web. En este caso el analista especificó que se utilizaría el documento de XML para crear
una lista desplegable que contenga todos los clientes actuales para la ubicación deseada. Una vez que el usuario
selecciona un cliente de la lista desplegable aparece más información sobre ese cliente específico, como se mues-
tra en el ejemplo.
<?xml version="1.0"?>
<clientes>
<nombre>
<telefono>
</clientes>
Salida de papel
Nuevo documento de XML
Documento de XML
Software XSLT
Teléfono inteligente (Smartphone)
Página Web
<?xml version="1.0"?>
<clientes>
<nombre>
<telefono>
</clientes>
FIGURA 11.17
El software de transformación de
lenguaje de estilo extensible
(XSLT) se puede utilizar para
crear documentos de XML y
transformarlos en muchos
formatos distintos para una
variedad de plataformas.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 359
<?xml version=“1.0” standalone=“no”?>
<?xml–stylesheet type=“text/xsl” href=“cust02.xsl” ?>
<clientes>
<titulo>Información del cliente</titulo>
<cliente>
<numero>09288</numero>
<nombre>
<apellidopaterno>Green</apellidopaterno>
<primernombre>George</primernombre>
<inicial_segnom>L</inicial_segnom>
</nombre>
<direccion>
<calle>123 Oak Street</calle>
<apartamento>Suite 16</apartamento>
<ciudad>Madison</ciudad>
<estado>WI</estado>
<cp>53704</cp>
<pais>Estados Unidos</pais>
</direccion>
<saldo_actual>123.45</saldo_actual>
</cliente>
<cliente>
<numero>15008</numero>
<nombre>
<apellidopaterno>Brown</apellidopaterno>
<primernombre>Sally</primernombre>
<inicial_segnom>S</inicial_segnom>
</nombre>
<direccion>
<calle>123 Elm Street</calle>
<apartamento>Apt. 1</apartamento>
<ciudad>Camden</ciudad>
<estado>NJ</estado>
<cp>08102</cp>
<pais>Estados Unidos</pais>
</direccion>
<saldo_actual>9,876.54</saldo_actual>
</cliente>
</clientes>
Información del cliente
Número:
Primer nombre:
Apellido paterno:
Calle:
Apartamento:
Ciudad:
Estado:
CP:
País:
Saldo actual:
09288
George
Green
123 Oak Street
Suite 16
Madison
WI
53704
United States
123.45
Número:
Primer nombre:
Apellido paterno:
Calle:
Apartamento:
Ciudad:
Estado:
CP:
País:
Saldo actual:
15008
Sally
Brown
123 Elm Street
Apt. 1
Camden
NJ
08102
United States
9,876.54
FIGURA 11.18
Una transformación de XML, con
el XML a la izquierda y el
resultado de la transformación a la
derecha. Sólo se incluyen en la
salida a la derecha los datos entre
las etiquetas.
FIGURA 11.19
Una página Web que utiliza Ajax
hace que sea posible mostrar
mucho menos datos en una página,
con lo cual se obtiene una pantalla
ordenada.www.xlibros.com

360 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
La ventaja de usar Ajax para mostrar datos es que el usuario no tiene que esperar a que aparezca una nueva
página Web después de realizar una selección. La filosofía de Ajax es mostrar preguntas limitadas para que el
usuario las responda en forma incremental. Esto elimina el desorden en la pantalla. Una vez que el usuario res-
ponde a una pregunta al hacer una elección, se puede generar una nueva pregunta.
E X P E R I E N C I A D E H Y P E R C A S E ® 1 1
“Yo diría que la recepción que obtuvo, o más bien que su equipo
obtuvo en relación con la presentación de su propuesta fue bastante
cálida. ¿Qué le pareció conocer al Sr. Hyatt? ¿Qué? ¿No asistió? Oh
[riéndose], el es su propio jefe. De todas formas no me preocuparía
mucho por eso. Los informes que obtuve de Snowden fueron alen-
tadores. De hecho, ahora él quiere ver algunos diseños preliminares
de todos ustedes. ¿Podrían tener algo en su escritorio o enviarlo
como adjunto en un correo electrónico en dos semanas? Él estará en
un viaje de negocios en Singapur la próxima semana, pero cuando
se recupere del desfase de horarios estará buscando esos diseños.
Gracias”.
Preguntas de HYPERCASE
1. Considere los informes de la Unidad de capacitación
(Training Unit). ¿Cuáles son las quejas de Snowden sobre
estos informes? Explique en un párrafo.
2. Use un formulario en papel de diseño, Microsoft Visio o una
herramienta Case para diseñar un prototipo de una pantalla
de salida con base en los informes de la Unidad de
capacitación que sintetizarán la siguiente información para
Snowden:
Número de proyectos aceptados en la Unidad de
capacitación.
Número de proyectos que se están reevaluando.
Áreas básicas de capacitación por las que se está solicitando
un consultor.
3. Diseñe una pantalla de salida adicional que usted crea que
apoyará a Snowden en el tipo de proceso de toma de
decisiones que realiza con frecuencia.
4. Muestre sus diseños a tres de sus compañeros de clase.
Obtenga retroalimentación por escrito de parte de ellos sobre
cómo mejorar las pantallas de salida que diseñó.
5. Rediseñe las pantallas para capturar las mejoras sugeridas
por sus compañeros de clase. Explique en un párrafo cómo
lidió con cada una de sus cuestiones.
FIGURA 11.HC1
Usted tiene la habilidad de ver y
criticar las pantallas de salida en
HyperCase.
RESUMEN
La salida es cualquier información o datos útiles que el sistema
de información o el sistema de soporte de decisiones entregan
al usuario. La salida puede tomar casi cualquier forma, inclu-
yendo la salida impresa, de pantalla, audio, microformas, CD-
ROM o DVD y documentos basados en Web.
El analista de sistemas tiene seis objetivos principales al
diseñar la salida: diseñar la salida para que sirva el propósito
previsto para los humanos y la organización, ajustarla al usua-www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 361
PALABRAS CLAVE Y FRASES
Ajax
CD-ROM
complemento (plug-in)
correo electrónico (email)
diseño de la salida
DVD
FAQ
fuentes RSS
hipertexto
hipervínculo
hoja de estilo en cascada (CSS)
Información constante
información variable
Java
localizador uniforme de recursos (URL)
marcador
navegador
página Web
pantalla
pegajosidad
podcasting
predisposición de la salida
salida de audio
salida electrónica
salida externa
salida interna
sistema de administración de contenido (CMS)
sitio Web
tablero de control
tablero electrónico de anuncios
transformación de lenguaje de estilo extensible (XSLT)
Weblogs (blogs)
Webmaster
PREGUNTAS DE REPASO
1. Mencione los seis objetivos que el analista persigue al diseñar la salida de un sistema.
2. Compare las salidas externas con las salidas internas producidas por el sistema. Recuerde que debe considerar las
diferencias en los usuarios externos e internos.
3. ¿Cuáles son tres situaciones que señalan a las impresoras como la mejor opción de tecnología de salida?
4. Mencione dos ejemplos en los que la salida de pantalla sea la mejor solución como opción de método de salida.
5. Mencione los métodos potenciales de salida electrónica para los usuarios.
6. ¿Cuáles son las desventajas de la salida electrónica y basada en Web?
7. Mencione diez factores a considerar al elegir la tecnología de salida.
8. ¿Qué tipo de salida es mejor si las actualizaciones frecuentes son una necesidad?
9. ¿Qué tipo de salida es deseable si muchos lectores van a leer, almacenar y revisar la salida durante cierto número de
años?
10. ¿Cuáles son las desventajas de la salida de audio?
11. Mencione tres formas en que las presentaciones de la salida se predisponen en forma no intencional.
12. ¿Cuáles son cinco formas en que el analista puede evitar la predisposición en la salida?
13. ¿Cuál es la diferencia entre la información constante y variable que se presenta en un informe?
14. ¿Por qué es importante mostrar a los usuarios un prototipo de un informe o una pantalla de salida?
15. Mencione seis elementos funcionales de los informes impresos.
16. Mencione cinco elementos estilísticos o estéticos de los informes impresos.
17. ¿En qué formas difieren las pantallas, la salida impresa y los documentos basados en Web?
18. Mencione cuatro lineamientos para facilitar el diseño de una buena salida de pantalla.
rio, entregar la cantidad correcta de salida, entregarla en el
lugar correcto, proveer la salida a tiempo y elegir el método
correcto.
Es importante que el analista tenga en cuenta que el con-
tenido de la salida está relacionado con el método de salida.
La salida de distintas tecnologías afecta a los usuarios de di-
ferentes formas. Las tecnologías de salida también difieren en
cuanto a su velocidad, costo, portabilidad, flexibilidad, accesi-
bilidad y posibilidades de almacenamiento y recuperación. Hay
que considerar todos estos factores al decidir entre la salida
impresa, de pantalla, de audio, electrónica o basada en Web, o
una combinación de éstas.
La presentación de la salida puede predisponer a los usua-
rios a la hora de interpretarla. Los analistas y los usuarios
deben estar conscientes de las fuentes de predisposición. Es
conveniente que los analistas interactúen con los usuarios para
diseñar y personalizar la salida, para informar a los usuarios
sobre las posibilidades de predisposición en la salida, para
crear una salida flexible y con capacidad de modificación, y
para capacitar a los usuarios de manera que utilicen varias sa-
lidas para ayudar a verificar la precisión de cualquier informe
específico.
Los informes impresos se diseñan mediante el uso de he-
rramientas de diseño de software asistido por computadora que
cuentan con plantillas de diseño e interfaces tipo “arrastrar y
soltar”. El diccionario de datos sirve como la fuente de los da-
tos necesarios en cada informe.
Es importante diseñar la salida para las pantallas de los
usuarios, en especial para DSS y Web. La estética y la utili-
dad son imprescindibles al crear una salida bien diseñada para
las pantallas. Es importante producir prototipos de pantallas
y documentos Web que animen a los usuarios a interactuar
con estos prototipos y realizar las modificaciones cuando se
desee.www.xlibros.com

362 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
19. ¿Qué diferencias hay entre la salida para un DSS y la salida para un MIS más tradicional?
20. ¿Cuáles son las cuatro consideraciones primarias que tiene el analista al diseñar la salida gráfica para los sistemas de
soporte de decisiones?
21. Defina el concepto de pegajosidad.
22. Mencione siete lineamientos para crear buenos sitios Web.
23. Mencione cinco lineamientos para usar gráficos al diseñar sitios Web.
24. Mencione siete ideas para mejorar la presentación de los sitios Web corporativos que diseñe.
25. ¿Cuál es la regla de los “tres clics”?
26. ¿En qué formas puede animar a las empresas a promover sus sitios Web que usted desarrolló?
27. ¿Cómo una hoja de estilo en cascada permite que el analista produzca la salida?
28. ¿Cuáles son las ventajas de usar XSLT en vez de una hoja de estilo en cascada?
29. ¿Qué son fuentes RSS?
30. ¿Cómo puede el administrador Web usar fuentes RSS?
31. ¿Cuál es el principal uso de los tableros de control?
32. ¿Qué son los widgets (o gadgets)?
33. ¿Por qué debe un diseñador de sistemas estar consciente de la popularidad de los widgets (o gadgets)?
34. ¿Cómo permite una hoja de estilo en cascada que el analista produzca la salida?
35. ¿Cuáles son las ventajas de usar una transformación de lenguaje de estilo extensible en vez de una hoja de estilo en
cascada?
36. ¿Cómo ayuda Ajax a construir páginas Web efectivas?
PROBLEMAS
1. “Estoy seguro de que no les importará si empezamos a enviar el informe en estas hojas de computadora extra grandes.
Todo este tiempo lo condensamos, reformulamos y lo enviamos a nuestras cuentas más grandes, pero ahora no podemos.
Hay tan poco personal que no tenemos el tiempo”, dice Otto Breth. “Voy a escribir un comentario aquí para decirles
cómo responder a este informe y así podremos enviarlo”.
a. ¿Qué problemas potenciales puede ver al cambiar la salida externa casualmente? Haga una lista.
b. Describa en un párrafo cómo pueden diferir las salidas externa e interna en cuanto a función y apariencia.
2. “No necesito verla muy seguido, pero cuando llega el momento tengo que poder revisarla rápidamente. Creo que
perdimos el último contrato debido a que la información que necesitaba estaba enterrada en una torre de papel en el
escritorio de alguien”, dice Luke Alover, un arquitecto que describe los problemas de la empresa a uno de los analistas
asignados al nuevo proyecto de sistemas. “Lo que necesito es información al instante sobre el costo que tenía un edificio
de esa medida en pies cuadrados la última vez que ofertamos; cuánto cuestan los materiales básicos como acero, vidrio y
concreto con nuestros tres principales proveedores; quién podría ser nuestra competencia en este tipo de construcción y
quién pertenece al comité que tomará la decisión final sobre quién ganó la subasta. Justo ahora, esta información se
encuentra en cien informes en alguna parte. Tengo que buscar en todos lados estos informes”.
a. Dados los detalles limitados que tenemos aquí, escriba un párrafo para sugerir un método de salida que Luke pueda
usar para resolver algunos de sus problemas actuales. Explique en un segundo párrafo sus razones para elegir el
método de salida que eligió (sugerencia: asegúrese de relacionar el método de salida con el contenido de la salida en
su respuesta).
b. El pensamiento actual de Luke es que no se debe mantener ningún registro en papel de la salida en cuestión.
Describa en un párrafo sobre los factores a sopesar antes de utilizar la salida de pantalla en vez de los informes
impresos.
c. Haga una lista de cinco a siete preguntas que usted haría en relación con la función de la salida en la organización a
Luke y a los demás antes de decidir deshacerse de cualquier informe impreso que se utilice en ese momento.
3. He aquí varias situaciones que requieren decisiones sobre el contenido de la salida, la metodología de salida, la
distribución, etcétera. Para cada situación observe la decisión de salida apropiada.
a. Un proveedor grande con buena reputación de materia prima clave para el proceso de producción de la empresa para
la que usted trabaja requiere un informe sintetizado de fin de año sobre los totales comprados a ese proveedor.
b. Se envían al personal memos internos sobre una lluvia de ideas en relación con los planes para un día de campo de
la empresa y la recaudación de fondos.
c. Un encargado de tomar decisiones clave necesita un informe sintetizado de la situación financiera de la empresa
para presentar una propuesta a los potenciales patrocinadores externos.
d. El personal de recepción requiere un listado de las reservaciones de cuartos de hotel de esta noche.
e. La policía local necesita un listado de las reservaciones de cuartos de hotel de esta noche.
f. Las patrullas de los estacionamientos utilizarán un conteo real de las personas que pasan por las puertas de Wallaby
World (un parque de diversiones australiano).
g. Un sistema de inventario debe registrar un artículo cada vez que se escanea mediante un lápiz óptico.
h. Veintidós supervisores utilizarán un informe sintetizado de los aumentos de salario por méritos asignados a cada uno
de los 120 empleados durante una reunión de supervisores; también utilizarán este informe para explicar los
aumentos en los sueldos por méritos a los empleados de los departamentos de cada supervisor.
i. Tres planeadores estratégicos en la organización requieren información competitiva, pero debe considerarse que
incluiría información delicada, en el caso que sea posible una divulgación más amplia.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 363
j. Se requiere un estilo casual de conversación para informar a los clientes sobre las características potentes pero raras
veces utilizadas de un producto.
k. Un distrito histórico de cierta ciudad desea informar a sus visitantes sobre los edificios y eventos históricos.
l. Hay que entregar advertencias sobre tormentas a los suscriptores en un área geográficamente extensa.
4. “Creo que ahora sé cuál era la intención de esa persona, pero me engañó por un instante”, dice la Srita. deLimit.
Ella está hablando sobre un prototipo de salida de pantalla diseñado por el analista de sistemas con el que habló
hace unos momentos. “Es decir, nunca consideré que fuera un problema el hecho de que no poder ajustar en una
clase ni el 20 por ciento del cupo total”, dice. “Sabemos que nuestras clases tienen buena demanda, pero como no
podemos contratar más maestros para cubrir las áreas que necesitamos, tuvimos que hacer ajustes en la demanda de
estudiantes. Él resaltó como problema el hecho de que sólo el 5 por ciento de los estudiantes que deseen tomar una
clase no puedan entrar, pero está bien. Ahora que sé lo que significa, sólo ignoraré a la computadora cuando emita
un sonido”.
a. Describa en uno o dos enunciados el problema al que se enfrenta la Srita. deLimit con la salida de pantalla.
b. ¿Es acaso su solución de “ignorar los sonidos” razonable, dado que la salida se encuentra en la etapa de prototipo?
c. Explique en un párrafo cómo se puede modificar la salida de pantalla para este problema específico, de manera que
refleje mejor las reglas del sistema que utiliza la Srita. deLimit.
5. La siguiente es una hoja de registro para un sistema de información de pacientes utilizado por las enfermeras de un
sanatorio para registrar los visitantes de los pacientes y las actividades durante sus turnos. Diseñe un informe impreso
mediante el uso de software de diseño de formularios que proporcione un resumen para la enfermera a cargo de cada
turno y un informe para el coordinador de actividades al final de una semana. Asegúrese de utilizar las convenciones
apropiadas para indicar los datos constantes, los datos variables y otros. Estos informes se utilizarán para determinar los
patrones de dotación de personal y los ofrecimientos de actividades a futuro.
6. Diseñe la salida de pantalla para el problema 5 mediante el uso de software de diseño de formularios. Haga todas las
suposiciones necesarias sobre la capacidad necesaria del sistema y siga las convenciones de diseño de pantallas para las
instrucciones en pantalla (Sugerencia: Puede usar más de una pantalla si lo desea.).
a. Describa en un párrafo por qué diseñó cada informe como lo hizo en los problemas 5 y 6. ¿Cuáles son las
principales diferencias en su metodología en cada problema? ¿Es posible trasplantar con éxito los informes impresos
a las pantallas sin necesidad de modificaciones? ¿Por qué sí o por qué no?
b. Algunas de las enfermeras están interesadas en un sistema basado en Web al que las familias de los pacientes puedan
acceder desde su hogar con una contraseña. Diseñe una salida de pantalla para Web. Describa en un párrafo cómo
tuvo que alterar su informe para que lo pudiera ver la familia de un paciente.
7. Clancy Corporation fabrica uniformes para los departamentos de policía a nivel mundial. Muchos grupos seleccionan
sus uniformes debido a su bajo costo y a su diseño simple pero digno. Usted va a ayudar a diseñar un DSS para Clancy
Corporation, quienes han solicitado una salida en formato tabular que les ayude a tomar varias decisiones en cuanto a los
diseñadores que deben usar, dónde comercializar sus uniformes y qué cambios hacer en los uniformes para que
conserven una apariencia actualizada. La siguiente tabla enlista algunos de los datos que la compañía desearía ver en
tablas, incluyendo los nombres de los estilos de uniformes, un ejemplo de un grupo comprador para cada estilo y los
diseñadores a cargo de los estilos de uniformes. Prepare un ejemplo de salida en formato tabular para pantalla que
incorpore estos datos sobre Clancy. Siga las convenciones apropiadas para las pantallas de salida en formato tabular. Use
códigos y una clave en donde sea apropiado.
Fecha Paciente Visitantes Relación Actividades
2/14 Clarke 2 Madre, padre Caminó por los pasillos, asistió a la capilla,
comidas en la cafetería
Coffey 6 Compañeros de trabajo Jugaron, hicieron fiesta en el cuarto
Martine 0 --------------- Comidas en el cuarto
Laury 4 Esposo y amigos Jugaron en la terraza interior, vieron TV
Finney 2 Padres Conversación, comidas en la cafetería
Cartwright 1 Hermana Conversación, salón de manualidades
Goldstein 2 Hermana, hermano Conversación, juegos fuera del cuarto, jacuzzi
Nombre del estilo Comprador de ejemplo Diseñadores
Militar completo NYPD Claudio, Rialtto, Melvine Mine
Semi militar LAPD Rialtto, Calvetti, Duran, Melvine Mine
Formal Fuerzas armadas australianas Claudio, Dundee, Melvine Mine
Casual “Miami Vice” Johnson, Melvine Minewww.xlibros.com

364 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Asegúrese de seguir las convenciones de diseño apropiadas para las pantallas. Use códigos y una clave si es
necesario.
b. Seleccione un segundo método para graficar que permita a los encargados de tomar decisiones de Clancy ver una
tendencia en la compra de ciertos estilos de uniformes específicos a través del tiempo. Dibuje una gráfica para
visualización como parte de la salida del DSS de Clancy. Asegúrese de seguir las convenciones de diseño apropiadas
para las pantallas. Use códigos y una clave si es necesario.
c. Describa en un párrafo las diferencias en los dos gráficos en pantalla que seleccionó. Defienda sus elecciones.
9. Michael Cerveris es propietario de varios autos de carreras. ¿Qué medidas de desempeño necesita desarrollar para llevar
registro del desempeño de su conductor, los mecánicos de pit y el personal de soporte (sin mencionar el gasto de las
llantas)?
10. Diseñe un tablero de control de DSS para Michael (problema 9). Use los tipos de diagramas y gráficos apropiados para
ilustrar el desempeño.
11. Diseñe un tablero de control para llevar el registro de las acciones y la cartera de clientes de una persona. Piense cómo
podría utilizar el tablero de control para tomar decisiones sobre comprar y vender acciones. Recuerde que un cliente
puede tener más de un corredor de bolsa.
12. Gabriel Shanks opera una compañía teatral sin fines de lucro que produce siete obras por año en tres teatros. Cada obra
dura ocho semanas, pero se puede extender cuatro semanas más si resulta un éxito. Diseñe un tablero de control para
Gabriel; tome en cuenta las distintas fases del montaje, así como la necesidad de vender todos los boletos que sea
posible. No olvide que Gabriel está involucrado en el teatro, es muy visual y no le gustan las tablas.
13. Mientras Gabriel (del problema anterior) se hace cargo de varios detalles durante un día ordinario, le gustaría estar al
tanto de las noticias de teatro en Manhattan y tener al mismo tiempo algunas herramientas simples a la mano para
ayudarle con sus actividades relacionadas con la computadora. ¿Qué tipo de widgets y gadgets necesitaría Gabriel para
hacer su trabajo y tener al mismo tiempo algunas herramientas simples basadas en computadora siempre disponibles?
14. Explore la Web para ver todos los sitios Web que estén mal y bien diseñados. Seleccione tres ejemplos de cada uno.
Comente sobre lo que hace que los sitios sean excelentes o malos; use el formulario de crítica que presentamos antes en
el capítulo para compararlos y contrastarlos.
15. Proponga un sitio Web para Clancy’s, la empresa de uniformes que describimos en los problemas 7 y 8. Haga un
bosquejo a mano o use software de diseño de formularios para crear un prototipo de la página de inicio de Clancy’s.
Indique los hipervínculos e incluya un bosquejo de un documento de hipervínculo. Recuerde incluir gráficos, iconos e
incluso sonido u otro tipo de medio apropiado. Describa en un párrafo quiénes son los usuarios previstos para el sitio
Web y por qué es conveniente que Clancy’s cuente con una presencia Web.
16. Las tiendas departamentales Elonzo’s son una cadena de aproximadamente 50 tiendas de ventas al detalle, las cuales se
especializan en artículos de cocina, baño y otros enseres domésticos, incluyendo muchos artículos decorativos y de
moda. Hace poco Elonzo’s decidió automatizar su registro de regalos para permitir que los invitados a las bodas y otros
eventos puedan ver los artículos seleccionados por los novios u otras personas.
a. Diseñe una página Web que permita a los clientes introducir un código postal y buscar la tienda más cercana.
b. Diseñe una página Web para que los clientes vean los regalos y puedan pedirlos en línea. No incluya los formularios
reales para los pedidos, sólo los productos. ¿Qué tipo de opciones estarían disponibles para los clientes? Incluya
botones o vínculos para cambiar la secuencia de orden en su diseño.
c. Diseñe una lista impresa que los clientes puedan solicitar cuando vayan a una de las tiendas. ¿Cuáles serían las
secuencias óptimas para un cliente que trata de buscar artículos? ¿Se incluirían todos los elementos solicitados por
los novios en la lista? (Sugerencia: tal vez ya se hayan comprado algunos.).
17. Diseñe el esquema de un podcast para alguien que pasea por su universidad, colegio o empresa. ¿En qué secuencia
colocaría los temas? ¿Cuánto tiempo asignaría para cada campus o ubicación? Suponga que el grupo llegará en la
mañana y tome en cuenta el almuerzo en el podcast.
18. Diseñe una pantalla de recordatorio de vuelos para un teléfono inteligente u otro dispositivo portátil.
19. Diseñe un estilo Ajax de página Web que permita al decano de un colegio comunitario seleccionar instructores
de medio tiempo. El decano debe ser capaz de seleccionar una disciplina o curso y hacer que el servidor envíe un
documento de XML que contenga todos los instructores potenciales de medio tiempo para la selección. Hay que usar
8. A los de Clancy les interesa una salida gráfica para su DSS. Desean ver una comparación gráfica de la cantidad de
uniformes de cada estilo que se venden al año.
a. Seleccione un estilo de gráfico apropiado y diseñe un gráfico para la pantalla de salida que incorpore los siguientes
datos:
Militar completo
(porcentaje del total) Semi militar Formal Casual
2005 50 20 20 10
2006 55 15 20 10
2007 60 15 15 10
2008 62 15 15 8
2009 65 10 15 10www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 365
el documento de XML para llenar una lista desplegable con los nombres de los instructores. Al hacer clic en el nombre
de un instructor debe aparecer información sobre ese instructor potencial. Decida qué información debe incluir para
ayudar al decano a tomar una decisión sobre el instructor que debe contratar (Sugerencia: Tal vez los instructores de
medio tiempo puedan enseñar sólo en ciertos días o sólo en la mañana, tarde o noche.).
PROYECTOS EN GRUPO
1. Haga una sesión de lluvia de ideas con los miembros de su equipo sobre los tipos de salida más apropiados para una
variedad de ejecutivos y gerentes de alto nivel de Dizzyland, un gran parque de diversiones en Florida. Incluya una lista
de entornos o situaciones de toma de decisiones y los tipos de salida. Describa en un párrafo por qué el grupo sugirió
opciones específicas para la salida.
2. Haga que cada miembro del grupo diseñe una pantalla o formulario de salida para las situaciones de salida que enlistó en
el proyecto en grupo 1 (use Microsoft Visio, una herramienta CASE o un formulario de diseño en papel para completar
cada pantalla o formulario).
3. Cree un tablero de control para los gerentes de Dizzyland del proyecto en grupo 1.
4. Diseñe un sitio Web, ya sea en papel o mediante el uso de software con el que esté familiarizado, para Dizzyland del
proyecto en grupo 1. Aunque puede bosquejar en papel los documentos o gráficos para tres niveles de páginas y los
hipervínculos requeridos, cree el prototipo de una página de inicio para Dizzyland; indique los hipervínculos en donde
sea apropiado. Obtenga retroalimentación de otros grupos en su clase y modifique su diseño de manera acorde. Describa
en un párrafo cómo es que diseñar un sitio Web difiere del diseño de pantallas para otros sistemas en línea.
5. Explore el sitio Web de Joomla! En www.joomla.org. ¿Cómo podría esta aplicación de código fuente abierto ayudarle a
implementar sus diseños del problema 4? Sintetice sus hallazgos en un párrafo. Use la Web para buscar otro CMS y
utilice un párrafo para compararlo con Joomla! Asegúrese de incluir el costo, la facilidad de uso, el soporte y la
disponibilidad en su comparación.
6. Use la lluvia de ideas para desarrollar un nuevo conjunto de widgets (gadgets) para aumentar la productividad. Haga una
lista con las cinco mejores ideas para nuevos wigdets.
BIBLIOGRAFÍA SELECCIONADA
Davenport, T. H. “Saving IT’s Soul: Human-Centered Information Management”. Harvard Business Review, marzo-abril 1994,
pp. 119-131.
Davis, G. B. y H. M. Olson. Management Information Systems, Conceptual Foundations, Structure, and Development, 2ª. Edi-
ción. Nueva York: McGraw-Hill, 1985.
Kendall, K. E. y J. E. Kendall. “DSS Systems Analysis and Design: The Role of the Analyst as Change Agent from Early DSS
to Mashups”, en Handbook of Decision Support Systems 2, editado por F. Burstein y C. W. Holsapple, pp. 293-312. Berlin:
Springer, 2008.
Souders, S. “High Performance Web Sites”. Communications of the ACM, Vol. 51, Núm. 12, diciembre de 2008, pp. 36-41.www.xlibros.com

366 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
E P I S O D I O 1 1
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Elaborar informes con base en las salidas
“Vamos a crear las especificaciones de la salida y después recorreremos al revés los diagramas de UML y el flujo de datos para
determinar los datos de entrada correspondientes”, dice Anna durante su siguiente reunión con Chip.
“Desde luego”, asiente Chip.
La salida se separó en dos categorías: informes y pantallas. Los informes se definieron con más detalle como informes
externos, tales como NOTIFICACIÓN DE SOFTWARE DE USUARIO (USER SOFTWARE NOTIFICATION) o los informes in-
ternos tales como LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING). Cada informe se
clasificó a su vez como detallado, por excepción o sintetizado.
Con base en las conversaciones con Paige Prynter, los analistas piensan que el INFORME DE INVERSIÓN DE HARD-
WARE (HARDWARE INVESTMENT REPORT) tiene la prioridad más alta. Se necesita lo más pronto posible debido a que el
proceso de presupuesto llegará pronto a una fase crítica y hay muchas solicitudes de nuevo hardware, así como actualizaciones
para el equipo existente.
El proceso utilizado para crear el INFORME DE INVERSIÓN DE HARDWARE (HARDWARE INVESTMENT RE-
PORT) es similar al proceso para crear todos los informes. Chip examina los diagramas de flujo de datos para el nuevo sistema
y localiza el flujo de datos identificado como INFORME DE INVERSIÓN DE HARDWARE (HARDWARE INVESTMENT
REPORT). Al hacer doble clic en el flujo de datos aparece la entrada en el repositorio para este informe.
“Estoy realmente feliz de que nos hayamos tomado el tiempo de documentar los prototipos de los informes y las pantallas
a la hora de crear los diagramas de flujo de datos”, recalca Chip. “Puedo identificar con facilidad los elementos requeridos para
producir el informe”.
Chip examina el repositorio para ver los detalles de cada elemento.
“Esto es magnífico”, exclama Chip. “Fue una buena idea definir todos los elementos mientras aprendíamos sobre ellos”.
Después Chip procede a crear un informe de ejemplo mediante el uso de Microsoft Access. Después del primer borrador,
Chip usa la herramienta Print Preview (Vista previa de impresión) para obtener una vista previa del informe.
“Hmm”, murmura Chip. “Algunos de los campos necesitan volver a ordenarse y el espaciamiento horizontal necesita al-
gunos ajustes”.
Chip modifica el diseño y lo vuelve a revisar. Para el tercer intento, el informe está en su forma final. El siguiente paso es
crucial: Chip pide a Paige que revise el informe y realice las modificaciones que desee. Chip le pregunta: “¿Hay alguna columna
adicional u otros datos faltantes que mejorarían la utilidad del informe? ¿Son todos los datos del informe necesarios?”.
Paige estudia la salida durante unos minutos y comenta: “Son necesarios los subtotales para cada MARCA (BRAND), inclu-
yendo el NÚMERO DE EQUIPOS (NUMBER OF MACHINES) y los totales generales. Recibimos solicitudes de distintos tipos
de máquinas, y conocer la cantidad de cada máquina solicitada nos puede ayudar a determinar lo que vamos a comprar”.
1/04/2010 Informe de inversión de hardware Página 1 de 1
Nombre de marca Modelo Número
de máquinas
Total
invertido
Xxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 3 $29,997.00
Subtotal de marca 3 $29,997.00
Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 4 $39,996.00
Xxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxx 2 $19,998.00
Subtotal de marca 6 $59,994.00
Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxx 3 $29,997.00
Xxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxx 11 $82,992.00
Subtotal de marca 14 $112,989.00
Total general 23 $202,980.00
FIGURA E11.1
Salida de ejemplo del INFORME
DE INVERSIÓN DE
HARDWARE (HARDWARE
INVESTMENT REPORT).www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 367
Chip regresa a su computadora y realiza los cambios necesarios. En la figura E11.1 se muestra el ejemplo final del IN-
FORME DE INVERSIÓN DE HARDWARE (HARDWARE INVESTMENT REPORT). Paige revisa de nuevo esta versión y
firma en el diseño para indicar que está completo.
La lógica para este informe sintetizado se describe en una especificación de proceso. La tabla COMPUTER (COMPUTADORA)
se ordena por MODELO (MODEL) dentro de MARCA (BRAND). Los totales se acumulan para cada MARCA y MODELO. Cuando
cambia la MARCA o el MODELO, se imprime una línea en el informe. Cuando ocurre un cambio en la MARCA, se imprimen los
SUBTOTALES DE MARCA (BRAND SUBTOTALS). Los TOTALES DE MARCA (GRAND TOTALS) se imprimen después de
procesar todos los registros.
Anna pasa cierto tiempo hablando con Cher Ware sobre sus necesidades de informes. Se describen varios informes impresos cuando
Cher hace la pregunta: “¿Recibiré informes en línea que pueda ver rápidamente y que contengan la información más reciente?”.
La discusión que le sigue a la pregunta genera la creación de varias consultas.
¿Cómo le gustaría ver las categorías de software?” pregunta Anna. “¿Le gustaría ver todo el software en una sola pantalla
extensa desplazable?”.
“Bueno, me gustaría tener alguna manera de buscar una categoría y después mostrar todo el software disponible para esa
categoría”, responde Cher. “También sería útil poder pasar a la categoría anterior y la siguiente”.
Anna crea la pantalla SOFTWARE POR CATEGORÍA (SOFTWARE BY CATEGORY) mediante un formulario de Mi-
crosoft Access, el cual se muestra en la figura E11.2. Hay un botón para buscar registros, así como botones para pasar a las
categorías anterior y siguiente. En el área inferior de la pantalla hay un área para mostrar los diversos paquetes de software para
la categoría. El campo SISTEMA OPERATIVO (OPERATING SYSTEM) se almacena como un código en la correspondiente
tabla de la base de datos y se convierte en la descripción del código en la pantalla.
Anna muestra a Chip y a Cher la pantalla completa. “Estoy impresionada”, exclama Cher. “¡Es exactamente lo que necesito!”
En ese momento entra Hy Perteks. “¿Qué está pasando?”, pregunta. Después de ver la consulta, comenta: “Me gustaría
que desarrollaran algunas páginas Web para las clases de capacitación”.
¿Qué tiene en mente?”, pregunta Chip.
“Bueno, he estado pensándolo”, le responde Hy. “Imagino que sería útil para los maestros y el personal poder buscar la
información sobre los cursos de software que planeamos ofrecer. Después podríamos agregar un formulario Web para que se
inscribieran en los cursos”.
“Sería divertido trabajar en eso”, comenta Chip. “Podríamos crear un vínculo a la página desde nuestros menús de Soporte
de tecnología (Technology Support)”.
“Yo también quiero participar”, responde Anna. “¿Qué le gustaría en la página?”.
“Me gustaría crear una página Web que muestre una lista de lo cursos, incluyendo el nivel, como principiante o intermedio,
y las fechas de inicio de cada curso”, le responde Hy.
Chip y Anna se ponen a trabajar en la página Web. Los campos se identifican y se agrupan en el flujo de datos CLASES
DE CAPACITACIÓN QUE SE OFRECEN (TRAINING CLASSES OFFERED), el cual se muestra en la pantalla de Visible
Analyst de la figura E11.3. Observe que se incluye la dirección Web como alias. Anna crea la página Web de intranet final, que
se muestra en la figura E11.4. Chip y Hy revisan la página.
“Me gustan los menús en la parte superior de la página y el submenú que se despliega debajo de ese menú al pasarle el
ratón por encima, para desplegar más opciones del menú”, comenta Chip.
“El calendario es muy útil para que el personal vea los cursos que están programados por fecha, con botones para cambiar
el mes y el año”, comenta Hy. “Es muy conveniente que cambien los cursos en forma dinámica cuando cambia el mes, día o
año. El usuario tendrá una experiencia sin complicaciones”.
FIGURA E11.2
Pantalla SOFTWARE POR
CATEGORÍA (SOFTWARE BY
CATEGORY) de Microsoft
Access.www.xlibros.com

368 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
“Sí, y creo que también es muy bueno permitir al personal modificar la forma en que aparecen los datos. A muchos miem-
bros del personal les gusta ver los cursos que se ofrecen en su campus”, comenta Chip.
“Agregaríamos algo de distinción si incluyéramos una imagen de la mascota”, comenta Hy, “y el lema de la universi-
dad”.
“Me pondré a trabajar en ello”, responde Anna. “Realmente son buenas sugerencias”.
Después de un tiempo, terminan la página Web final y Hy la aprueba.
“Voy a enviar un email a todos los maestros y el personal, junto con un vínculo sobre nuestra ‘Nueva y mejorada’ página
Web”, comenta Hy. “Gracias por incluir mi dirección de correo electrónico. Será de utilidad para facilitar el proceso de registro
para los cursos y contestar cualquier pregunta. ¡Creo que realmente estamos progresando!”.
Para realizar los siguientes ejercicios, puede diseñar el informe o pantalla mediante formularios de diseño, o crearlos a
través de cualquier procesador de palabras con el que esté familiarizado. Los campos y demás información relacionada con los
informes se incluyen en las entradas del repositorio de flujo de datos de Visible Analyst o en una página Web que contiene una
copia del repositorio. La página Web contiene vínculos a los demás elementos en el repositorio para facilitar el proceso de ver
una entrada del repositorio y saltar hacia otra entrada para atrás o para adelante. En cada ejercicio se enlistan los nombres para
el flujo de datos.
Clases de capacitación que se ofrecen
Una página de intranet que indica las próximas clases de capacitación a
ofrecer por medio del Centro de información. Mostrar todas las clases para
cada paquete de software.
Titulo +
Version +
Nombre sistema operativo +
{Nombre clase} +
{Duracion clase} +
{Fecha inicial}
La página principal debería indicar el software, con vínculos a las
clases de capacitación y las fechas de inicio para el software. Incluir
la dirección de correo electrónico del instructor de capacitación en la
página principal para consultas sobre la capacitación.
FIGURA E11.3
Pantalla del flujo de datos
CLASES DE CAPACITACIÓN
QUE SE OFRECEN (TRAINING
CLASSES OFFERED).
FIGURA E11.4
Una página Web habilitada con
Ajax para la Central Pacific
University.www.xlibros.com

CAPÍTULO 11 • DISEÑO DE UNA SALIDA EFECTIVA 369
Se crearon los informes y formularios en Microsoft Access correspondientes. Toda la información está presente en la base
de datos de Microsoft Access; usted sólo tiene que modificar los informes y pantallas existentes para producir las versiones
finales. Para hacer las modificaciones, haga clic en el informe o pantalla deseada y después haga clic en el botón Design (Di-
seño). Puede realizar las siguientes modificaciones. El Page Header (Encabezado de página) contiene los encabezados de las
columnas. El área Detail (Detalle) contiene los campos a imprimir para el informe.
Haga clic en un campo para seleccionarlo. Haga clic en varios campos mientras oprime la tecla Mayús para
seleccionarlos.
Arrastre un campo (o campos) seleccionado para moverlo.
Haga clic en una de las cajas pequeñas que rodean el campo para cambiar su tamaño.
Seleccione varios campos, haga clic en Format (Formato) y después en una de los siguientes opciones:
Align (Alinear), para alinear todos los campos con el campo superior, izquierdo, etc.
Size (Ajustar tamaño), para hacer todos los campos iguales al campo más ancho, más alto, etcétera.
Horizontal Spacing (Espacio horizontal), para hacer el espacio horizontal igual, aumentarlo o reducirlo.
Vertical Spacing (Espacio vertical), para hacer el espacio vertical igual, aumentarlo o reducirlo.
EJERCICIOS
E-1. Use Microsoft Access para ver el INFORME DE INVERSIÓN DE HARDWARE (HARDWARE INVESTMENT RE-
PORT). Si está familiarizado con Microsoft Access, utilice la opción de menú File/Export... (Archivo/Exportar...)
para guardar el informe como página Web. Cuando se abra el cuadro de diálogo Export (Exportar), haga clic en la lista
desplegable Save As Type (Guardar como) y seleccione HTML Documents (Documentos HTML).
E-2. Chip, Dot y Mike participaron en varias sesiones de lluvias de ideas que produjeron como resultado los esquemas de
varios informes. Diseñe (o modifique mediante Access) el INFORME MAESTRO DE HARDWARE (HARDWARE
MASTER REPORT). Este informe es extenso, por lo que tendrá que ser cuidadoso para incluir todos los datos en el área
del informe. Tal vez quiera tener varias líneas de detalles para cada registro. Imprima el informe completo.
E-3. Después de reunirse con Cher Ware y Hy Perteks para hablar sobre las necesidades de los informes, Anna identificó los
campos para el INFORME DE NUEVO SOFTWARE INSTALADO (NEW SOFTWARE INSTALLED REPORT) par-
cialmente completo. Diseñe (o modifique) el informe para incluir los elementos encontrados en la entrada en el reposi-
torio de flujo de datos. ¿Es el informe detallado o sintetizado? Describa en un párrafo la lógica que usted cree que debe
usar el programa para producir informes.
E-4. Tanto Dot como Mike necesitan saber cuando se reciban nuevas computadoras. Cree el INFORME DE RECEPCIÓN DE
NUEVAS COMPUTADORAS (NEW COMPUTER RECEIVED REPORT). El flujo de datos INFORME DE COMPU-
TADORAS RECIBIDAS (COMPUTER RECEIVED REPORT) contiene los elementos necesarios.
E-5. Diseñe el INFORME MAESTRO DE SOFTWARE (SOFTWARE MASTER REPORT) que contiene información perti-
nente para ayudar a Cher y a Hy a localizar las diversas copias de cualquier paquete de software con facilidad. Los ele-
mentos necesarios para producir el informe se encuentran en el flujo de datos del INFORME MAESTRO DE SOFTWARE
(SOFTWARE MASTER REPORT).
Hay que imprimir en grupo los elementos TÍTULO (TITLE), VERSIÓN (VERSION), NOMBRE DEL SISTEMA
OPERATIVO (OPERATING SYSTEM NAME), EDITOR (PUBLISHER), CATEGORÍA (CATEGORY), PRIMER
NOMBRE (FIRST NAME) y APELLIDO PATERNO (LAST NAME) del experto de software. Se deben incluir totales
para cada combinación de TÍTULO/SISTEMA OPERATIVO/VERSIÓN. Imprima el diseño del informe completo.
E-6. Diseñe el LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING) que muestre las
computadoras disponibles en cada sala de cada campus. El campo CAMPUS deberá ser la DESCRIPCIÓN DEL CAM-
PUS (CAMPUS DESCRIPTION) y no el código que representa al campus.
E-7. Diseñe el INFORME DE COMPUTADORAS INSTALADAS (COMPUTER INSTALLED REPORT) que muestre las
computadoras personales instaladas en cada sala. Use la DESCRIPCIÓN DEL CAMPUS e imprima por grupos en base
a DESCRIPCIÓN DEL CAMPUS y UBICACIÓN DE SALA (ROOM LOCATION).
E-8. Use Microsoft Access para ver el informe de pantalla SOFTWARE POR CATEGORÍA (SOFTWARE BY CATEGORY).
Haga clic en el botón Find (Buscar) y localice CASE toolset (Conjunto de herramientas CASE). Haga clic en los
botones Next (Siguiente) y Previous (Anterior) para ver los elementos siguiente y anterior de Software Categories
(Categorías de software).
E-9. Diseñe el informe de pantalla SOFTWARE POR MÁQUINA (SOFTWARE BY MACHINE). Consulte los elementos en
la entrada en el repositorio de flujo de datos.
E-10. Diseñe el INFORME DE PROBLEMAS DE COMPUTADORAS (COMPUTER PROBLEM REPORT). Este informe
muestra todas las computadoras que tienen una gran cantidad de reparaciones o un costo extenso de reparación. Consulte
los elementos en la descripción del repositorio para el flujo de datos o modifique el informe de Microsoft Access.
E-11. Diseñe o modifique el INFORME DE INSTALACIÓN (INSTALLATION REPORT). Consulte los elementos en la en-
trada del repositorio para el flujo de datos. Este informe muestra las computadoras que se recibieron hace poco y que
están disponibles para la instalación.www.xlibros.com

370 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
E-12. Diseñe el INFORME DE NUEVAS COMPUTADORAS QUE SE RECIBIERON (NEW COMPUTER RECEIVED
REPORT). Consulte los elementos en la descripción en el repositorio para el flujo de datos o modifique el informe de
Microsoft Access. Este informe sintetizado muestra el número de computadoras de cada marca y modelo. Hay que des-
empacar estas computadoras para instalarlas en las salas.
E-13. Diseñe o modifique el INFORME DE MANTENIMIENTO PREVENTIVO (PREVENTIVE MAINTENANCE RE-
PORT). Consulte los elementos en la entrada del repositorio para el flujo de datos. Este informe muestra las computado-
ras que necesitan mantenimiento preventivo.
E-14. Diseñe el INFORME DE REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS REFERENCE RE-
PORT). Consulte los elementos en la descripción en el repositorio para el flujo de datos o modifique el informe de Mi-
crosoft Access. Este informe muestra la computadora en la que está instalado cada paquete de software. Se imprimen en
grupo los elementos TÍTULO (TITLE), VERSIÓN (VERSION), SIGNIFICADO DE SISTEMA OPERATIVO (OPE-
RATING SYSTEM MEANING) y EDITOR (PUBLISHER). Las líneas de detalle bajo el grupo contienen datos que
muestran la máquina, campus de instalación y sala.
E-15. Diseñe o modifique el INFORME DE PEDIDOS PENDIENTES DE COMPRAS DE COMPUTADORAS (OUTSTAN-
DING COMPUTER PURCHASE ORDERS REPORT). Consulte los elementos en la entrada del repositorio para el flujo
de datos. Este informe se debe producir para todos los registros ORDEN DE COMPRA (PURCHASE ORDER) que
tengan un código de orden de compra de M101, el cual representa a las computadoras, con la condición adicional de que
la CANTIDAD ORDENADA (QUANTITY ORDERED) en el registro debe ser mayor que la CANTIDAD RECIBIDA
(QUANTITY RECEIVED). Indique en un párrafo si este informe es sintetizado, por excepción o detallado y explique el
por qué.
E-16. Diseñe el INFORME DE INVERSIÓN DE SOFTWARE (SOFTWARE INVESTMENT REPORT). Consulte los ele-
mentos en la descripción en el repositorio para el flujo de datos o modifique el informe de Microsoft Access.
E-17. Diseñe la página Web REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS REFERENCE). Consulte
los elementos de la página Web en la descripción en el repositorio de software para el flujo de datos del INFORME DE
REFERENCIAS CRUZADAS DE SOFTWARE (SOFTWARE CROSS REFERENCE REPORT). Esta página Web
muestra las computadoras en las que está instalado cada paquete de software. Incluya una lista desplegable de software
que permita al usuario seleccionar un paquete de software. El diseño usa Ajax para actualizar la lista de computadoras
en la página Web que contiene el software y sus ubicaciones.
E-18. Diseñe la página Web LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING), que
muestre las computadoras disponibles en cada sala de cada campus. El CAMPUS se selecciona de una lista desplegable
que muestra la DESCRIPCIÓN DEL CAMPUS (CAMPUS DESCRIPTION). Cuando el usuario selecciona el nombre
de un campus de la lista desplegable, la página Web usa técnicas de Ajax para llenar la lista desplegable de salas del
campus. Al seleccionar una sala, la página Web usa Ajax para mostrar las máquinas ubicadas en cada sala. Use el repo-
sitorio para el LISTADO DE INVENTARIO DE HARDWARE (HARDWARE INVENTORY LISTING) sin el número
total de máquinas en campus o el número total de máquinas.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar archivos de ejemplo de Microsoft Visio o un proyecto de Visible Analyst, además de una base de
datos de Microsoft Access que pueden usar para completar los ejercicios.www.xlibros.com

371
C A P Í T U L O 1 2
Diseño de una entrada efectiva
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Diseñar formularios de entrada funcionales para los usuarios de sistemas empresariales.
2. Diseñar pantallas de entrada atractivas para los usuarios de sistemas de información.
3. Diseñar formularios de entrada útiles para las personas que interactúan en la Web.
4. Diseñar páginas de entrada útiles para los usuarios de intranets y de Internet.
Los usuarios merecen una salida de calidad. En buena medida, la calidad de la
entrada del sistema determina la calidad de su salida. Es vital que los formula-
rios de entrada, pantallas y documentos Web interactivos se diseñen teniendo
en cuenta esta relación crítica.
Los formularios de entrada, las pantallas y los formularios interactivos para
llenar a través de la Web bien diseñados deben cumplir con los objetivos de efectividad, precisión, facilidad
de uso, consistencia, simpleza y atracción. Podemos alcanzar todos estos objetivos debemos apegarnos a
los principios básicos de diseño, conocer lo que se requiere como entrada para el sistema y comprender la
forma en que los usuarios responden a los distintos elementos de los formularios y pantallas.
La efectividad significa que los formularios de entrada, las pantallas de entrada y los formularios a
llenar en Web sirvan a propósitos específicos para los usuarios del sistema de información, mientras que
la precisión se refiere a la certeza que el diseño proporcione para el llenado adecuado. La facilidad de uso
significa que los formularios y pantallas sean simples, de manera tal que el usuario requiera el mínimo
tiempo posible para descifrar su estructura. La consistencia implica que todos los formularios de entrada,
sean pantallas de entrada o formularios a llenar en Web, agrupen los datos de manera similar de una
aplicación a otra, mientras que simpleza se refiere a mantener esos mismos diseños ordenados de
una manera que el usuario enfoque su atención en ellos. En cuanto a la atracción, significa que los usua-
rios disfruten al usar los formularios de entrada debido a su diseño agradable.
DISEÑO DE BUENOS FORMULARIOS
El analista de sistemas debe ser capaz de diseñar un formulario completo y útil; los formularios
innecesarios desperdician los recursos de una organización.
Los formularios son instrumentos importantes para dirigir el curso de trabajo. Son documentos
impresos que las personas deben llenar de manera estandarizada. Los formularios solicitan y captu-
ran la información requerida por los miembros de la organización que, a menudo, se introducirá en la
computadora; por medio de este proceso, sirven como documentos fuente para los usuarios o constitu-
yen el origen de los datos que los humanos deben introducir en aplicaciones de comercio electrónico.
Para diseñar formularios útiles debemos tener en cuenta los siguientes cuatro lineamientos de
diseño de formularios:
1. Que los formularios sean fáciles de llenar.
2. Que cumplan con el propósito para el que se diseñaron.
3. Que su diseño contribuya a que se completen con precisión.
4. Que sean atractivos.
En las siguientes secciones veremos cada uno de estos cuatro lineamientos por separado.www.xlibros.com

372 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Hacer que los formularios sean fáciles de llenar
Para reducir los errores, agilizar el proceso de completarlos y facilitar la introducción de los datos, es esencial que
los formularios sean fáciles de llenar. El costo de los formularios es mínimo si se compara con el del tiempo que in-
vierten los empleados en llenarlos y después en introducir los datos en el sistema de información. Con frecuencia
es posible eliminar el segundo paso mediante el uso del envío electrónico, en el que los mismos usuarios teclean los
datos, desde los sitios Web establecidos para transacciones de comercio electrónico o solicitud de información.
FLUJO DEL FORMULARIO Un formulario con un flujo apropiado reduce el tiempo y esfuerzo que invierten los
empleados en llenarlo. Los formularios deben fluir de izquierda a derecha y de arriba abajo. Un flujo ilógico
requiere tiempo adicional y es frustrante. Un formulario en el que las personas tienen que pasar directamente a la
parte inferior y después saltar hacia la parte superior para terminarlo exhibe un mal flujo.
SIETE SECCIONES DE UN FORMULARIO Hay un segundo método que facilita a las personas llenar los formularios
en forma correcta; éste se enfoca en agrupar la información en forma lógica. Las siete secciones principales de
un formulario son:
1. Encabezado.
2. Identificación y acceso.
3. Instrucciones.
4. Cuerpo.
5. Firma y verificación.
6. Totales.
7. Comentarios.
Lo ideal es que estas secciones aparezcan agrupadas como en el recibo de gastos de empleado de Bakerloo Bro-
thers, de la figura 12.1. Observe que las siete secciones abarcan la información básica requerida en la mayoría de
los formularios. El tercio superior del formulario se dedica a tres secciones: encabezado, sección de identificación
y acceso, y sección de instrucciones.
Por lo general, la sección del encabezado incluye el nombre y la dirección de la empresa que creó el formu-
lario. La sección de identificación y acceso incluye códigos que se pueden usar para archivar el informe y obte-
ner acceso al mismo en una fecha posterior (en el capítulo 13 veremos con detalle cómo acceder a la información
con claves especiales en una base de datos). Esta información es muy importante cuando una organización debe
archivar el documento durante varios años. La sección de instrucciones indica cómo llenar el formulario y a
dónde se debe enviar al terminar de llenarlo.
La parte media es su cuerpo, el cual representa aproximadamente la mitad del formulario. En esta parte, la
persona que lo llena debe poner más detalle y elaboración. El cuerpo es la parte del formulario que probable-
mente contendrá datos explícitos y variables.
El tercio inferior del formulario está compuesto de tres secciones: firma y verificación, totales y comenta-
rios. Requerir totales finales y un resumen de los comentarios es una forma lógica de que la persona que llena el
formulario termine de hacerlo.
Hay una característica más a resaltar sobre el formulario de Bakerloo Brothers. El diseño del formulario
provee una doble verificación interna, con totales de columnas y totales de filas que deben dar como resul-
tado el mismo número. Si los totales de fila y de columna no dan el mismo resultado, el empleado que está
llenando el formulario sabrá que hay un problema y podrá corregirlo en ese instante. Se evita un error y el
empleado puede recibir el reembolso de la cantidad pendiente; ambos resultados se atribuyen a un diseño ade-
cuado del formulario.
LEYENDAS El uso de leyendas claras es otra técnica para facilitar el trabajo de llenar un formulario. Las leyendas
indican a la persona que completa el formulario lo que debe poner en una línea, espacio o cuadro en blanco. En
la figura 12.2 se muestran varias opciones para las leyendas. Se muestran dos tipos de leyendas de línea, dos
tipos de leyendas de verificación y ejemplos de una leyenda enmarcada y una leyenda de tabla.
La ventaja de poner la leyenda debajo de la línea es que hay más espacio en la línea para los datos; la des-
ventaja es que algunas veces no está claro cuál línea está asociada con la leyenda, si la de arriba o la de abajo.
Las leyendas de línea pueden estar a la izquierda de los espacios en blanco, a la misma altura, o se pueden
imprimir debajo de la línea en la que se van a introducir los datos.
Otra forma de usar leyendas es proveer un cuadro para los datos en vez de una línea. Las leyendas se pue-
den colocar en el interior, encima o debajo del cuadro. Los cuadros en los formularios ayudan a las personas a
introducir los datos en el lugar correcto y facilitan a la persona que recibe el formulario el proceso de leerlo. La
leyenda debe usar un tamaño de letra pequeño, de manera que no domine el área de entrada. Es posible incluir
pequeñas marcas de verificación en el cuadro si los datos se van a introducir en un sistema computarizado. Siwww.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 373
no hay suficiente espacio en un registro para los datos, la persona que llena el formulario (en vez del opera-
dor que introducirá los datos) tiene la libertad de determinar cómo se deben abreviar los datos. Las leyendas
también pueden incluir pequeñas notas aclaratorias para ayudar al usuario a introducir la información correcta-
mente, como Fecha (MM/DD/AAAA) o Nombre completo (Apellido paterno, apellido materno, Nombre(s)).
No importan los estilos de leyendas de línea que se elijan, es imprescindible emplearlos de manera consis-
tente (por ejemplo, sería confuso tratar de llenar un formulario diseñado con leyendas tanto arriba como debajo
de las líneas).
Las leyendas de verificación son una mejor opción cuando es necesario restringir las opciones de respuesta.
Observe la lista de métodos de viaje que se muestran para el ejemplo de verificación vertical en la figura anterior. Si
se va a rembolsar los gastos del empleado en el viaje de negocios sólo para los métodos de viaje de la lista, un sis-
tema de verificación es más conveniente que una línea en blanco. Este método tiene la ventaja adicional de recordar
a la persona que verifica los datos que debe buscar un talón de boleto de avión o cualquier otro recibo relacionado.
Una leyenda de verificación horizontal también es mejor opción que una leyenda de línea cuando la infor-
mación requerida es rutinaria y constante. Como ejemplo podemos citar un formulario que solicita los servicios
de uno de los siguientes departamentos: Laboratorio fotográfico, Departamento de impresión, Mantenimiento o
RECIBO DE GASTOS DE EMPLEADO
Solicitante: No escriba en las áreas
sombreadas.
Nombre completo del empleado
Departamento Número de sala
Número de ID del empleado
ENLISTE LOS GASTOS PARA CADA DÍA POR SEPARADO. ADJUNTE RECIBOS PARA LOS GASTOS EXCEPTO
ALIMENTOS, TAXIS Y ARTÍCULOS MISCELÁNEOS MENORES A $3.00. DETALLE TODOS LOS GASTOS MISCELÁNEOS.
Fecha
/ /
Lugar
Ciudad, Estado
Gastos de
alimentación
Gastos de
hospedaje Millas Costo
Automóvil
Descripción Costo
Misceláneos Costo
total
Costo
del taxi
Certifico que toda la información anterior es correcta
Formulario BB-104 01/2009
Firma del solicitante
Aprobado por
Fecha
Fecha
Totales
Bakerloo Brothers
Número de recibo
Se realizó una acción sobre:
FIGURA 12.1
En un formulario bien diseñado
hay siete secciones que ayudan a
fomentar que se complete.www.xlibros.com

374 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Nombre
Nombre Apellido paterno
Apellido paterno
Título Teléfono ( ) –
Nombre
Título
Título
Marque el método de viaje:
Avión
Tren
Auto de la empresa
Auto personal
Teléfono
Apellido paterno
Teléfono
– –
– –
Laboratorio fotográfico
Cantidad
Departamento de impresión Mantenimiento Provisiones
Unidad Descripción de artículo Costo del usuario Costo expandido
Subtotal
Impuesto de venta
Total
Leyenda de línea
Leyenda debajode la línea
Leyenda enmarcada
Lista de verificaciónvertical Lista de verificaciónhorizontal
Leyenda de tabla
FIGURA 12.2
Alternativas principales para usar
leyendas.
Provisiones. Estos departamentos proveen servicios de rutina a otros en la organización y no es probable que va-
yan a cambiar rápidamente.
Las leyendas de tabla funcionan bien en el cuerpo de un formulario donde se requieren detalles. Cuando
un empleado llena de manera apropiada un formulario con leyendas de tabla, está creando una tabla para la si-
guiente persona que recibirá el formulario, con lo cual ayuda a organizar los datos en forma coherente.
También se puede utilizar con efectividad una combinación de leyendas: por ejemplo, leyendas de tabla para
especificar categorías como cantidad, y leyendas de línea para indicar dónde deben estar el subtotal, los impues-
tos de venta y el total. Como las distintas leyendas sirven para propósitos diferentes, por lo general es necesario
emplear varios estilos de leyendas en cada formulario.
Cumplir con el propósito previsto
Los formularios se crean para servir a uno o más propósitos en los procesos de registrar, procesar, almacenar
y recuperar la información para las empresas. Algunas veces es conveniente proveer distinta información a loswww.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 375
diferentes departamentos o usuarios y compartir al mismo tiempo cierta información básica. Aquí es donde son
útiles los formularios especializados.
El término formulario especializado también se puede referir sólo a la manera en que la papelería prepara
los formularios. Algunos ejemplos de formularios especiales de papelería son los formularios de tantos múltiples
que se utilizan para crear triplicados instantáneos de los datos, los formularios de alimentación continua que pue-
den pasar por la impresora sin necesidad de intervención humana y los formularios perforados que dejan un talón
como registro cuando se separan.
Asegurar que se llenen en forma precisa
Por lo general, las tasas de errores asociadas con la recolección de los datos disminuyen de manera considerable
cuando los formularios se diseñan de tal forma que sea obvia la manera en que deben completarse con precisión.
El diseño es importante para asegurar que las personas hagan lo correcto con el formulario siempre que lo uti-
licen. Cuando los empleados de servicio, como los que leen medidores o toman inventario, usan dispositivos
portátiles para escanear o teclear los datos en el sitio apropiado, se evita el paso adicional de tener que transcribir
los datos para introducirlos en la computadora. Los dispositivos portátiles utilizan la transmisión inalámbrica o
se conectan a los sistemas computarizados más grandes para poder descargar los datos que el trabajador de servi-
cio almacenó en ellos. No es necesario transcribir lo que ocurrió en el campo.
Mantener los formularios atractivos
Aunque dotar a los formularios de atractivo se deja al último, esto no significa que sea menos importante: se
hace de esta forma debido a que para producir formularios atractivos hay que aplicar las técnicas descritas
en las secciones anteriores. Los formularios estéticos atraen a las personas y éstas se sienten animadas para
completarlos.
Los formularios deben lucir ordenados. Para ser atractivos, deben solicitar la información en el orden es-
perado: la convención dicta que se debe pedir nombre, dirección, ciudad, estado y código postal (y país, de ser
necesario). La distribución y el flujo apropiados contribuyen al atractivo de un formulario.
Utilizar distintos tipos de letra en el mismo formulario puede ser útil para que a los usuarios se les haga más
atractivo llenarlo. Separar las categorías y subcategorías con líneas gruesas y delgadas también puede fomentar
el interés. Los tipos de letras y los grosores de las líneas son elementos de diseño útiles para capturar la atención
y hacer que las personas se sientan con la seguridad de que llenan el formulario en forma correcta.
Hay paquetes de diseño de formularios disponibles para PC. La figura 12.3 muestra cómo se puede crear
formularios mediante el uso de software que permite al analista automatizar con rapidez los procesos de negocios
para los que ya existen formularios en papel. El analista puede usar un conjunto de herramientas para configurar
campos, casillas de verificación, líneas, cuadros y muchas otras características. También es posible digitalizar
formularios en papel para después publicarlos en la Web.
FIGURA 12.3
El software permite a un usuario
tomar un formulario existente,
escanearlo en la computadora y
definir campos de manera que se
pueda llenar fácilmente en una PC.www.xlibros.com

376 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Cómo controlar los formularios de las empresas
Controlar los formularios de las empresas es una tarea importante; a menudo cuentan con un especialista en
formularios que se encarga de llevar el control, pero algunas veces este trabajo recae en el analista de sistemas,
quien se encarga de establecer e implementar el control de los formularios.
Las tareas básicas para controlar formularios incluyen asegurar que cada formulario en uso cumpla con
su propósito específico para ayudar a los trabajadores a realizar sus tareas y que el propósito especificado sea
integral para el funcionamiento de la organización, de manera que se evite la duplicación de la información re-
copilada y de los formularios correspondientes; diseñar formularios efectivos, decidir sobre cómo reproducirlos
en la forma más económica posible y establecer procedimientos que los pongan a disposición de los empleados
(cuando sea necesario) al menor costo posible. A menudo, para esto se requiere que los formularios estén dispo-
nibles en Web para poder imprimirlos. Hay que incluir en cada formulario un número único y una fecha de revi-
sión (mes/año), independientemente de que se llene y envíe en forma manual o electrónica. Esto ayuda a que los
usuarios sean organizados y eficientes.
DISEÑO DE BUENOS FORMULARIOS WEB Y DE PANTALLA
Gran parte de lo dicho sobre el diseño de buenos formularios se puede transferir al diseño de pantallas, sitios y
páginas Web. Una vez más, el usuario debe permanecer en primer lugar en los pensamientos del analista durante
el diseño de las pantallas.
Sin embargo, existen algunas diferencias por las que los analistas de sistemas se deben esforzar para tener en
cuenta las cualidades únicas de las pantallas, en vez de adoptar a ciegas las convenciones de los formularios de
papel. Una de las principales diferencias es la presencia constante de un cursor en la pantalla, el cual orienta al
usuario en cuanto a la posición actual para introducir datos. A medida que se introducen los datos en pantalla, el
cursor avanza un carácter hacia delante para señalar el camino.
Otra diferencia importante entre los formularios electrónicos, de Web y estáticos es que los diseñadores pue-
den incluir ayuda sensible al contexto para el usuario en cualquier formulario de llenado electrónico. Esta prác-
tica puede reducir la necesidad de mostrar instrucciones para cada línea, con lo cual se reduce el desorden y las
llamadas a Soporte técnico. Al usar una metodología basada en Web, el diseñador también puede aprovechar
los hipervínculos, con lo cual asegura que los formularios se llenen correctamente al dar ejemplos con hiper-
vínculos de formularios llenados en forma correcta.
En esta sección presentaremos los lineamientos para el diseño efectivo de pantallas. Los presentaremos en
orden para ayudar en la obtención de las metas generales de diseño de la entrada: efectividad, precisión, facilidad
de uso, simpleza, consistencia y atractivo.
Los cuatro lineamientos para el diseño de pantallas son importantes pero no exhaustivos. Como vimos en el
capítulo 11, incluyen lo siguiente:
1. Mantener la pantalla simple.
2. Mantener la presentación de la pantalla consistente.
3. Facilitar el movimiento del usuario entre las pantallas y páginas de visualización.
4. Crear una pantalla atractiva y agradable.
En las siguientes subsecciones desarrollaremos cada uno de estos lineamientos y presentaremos muchas técnicas
de diseño para observar los cuatro lineamientos.
Mantener la pantalla simple
El primer lineamiento para el buen diseño de pantallas es mantener la pantalla simple. La pantalla debe mostrar
sólo lo necesario para la acción específica a realizar. Para el usuario ocasional, el 50 por ciento del área de la
pantalla debe contener información útil.
TRES SECCIONES DE LA PANTALLA La salida de pantalla se debe dividir en tres secciones. La parte superior está
constituida por una sección de “encabezado”: contiene los títulos de software y de archivos abiertos, menús
desplegables e iconos que realizan ciertas tareas.
La sección media se denomina el “cuerpo” de la pantalla. El cuerpo se puede usar para introducir datos; se
organiza de izquierda a derecha y de arriba hacia abajo debido a que las personas en las culturas occidentales
mueven sus ojos por una página de esta forma. Las leyendas e instrucciones se deben suministrar en esta sec-
ción para ayudar al usuario a introducir los datos pertinentes en el lugar correcto. También puede haber ayuda
sensible al contexto disponible cuando el usuario haga clic en el botón derecho del ratón en la sección del
cuerpo de la pantalla.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 377
O P O R T U N I D A D D E C O N S U L T O R Í A 1 2 . 1
Este formulario puede ser dañino para su salud
la figura 12.C1 muestra un formulario impreso de historial mé-
dico que el Dr. Mike Robe, médico familiar, hace a su recepcionista
entregar a todos los pacientes nuevos, quienes deben llenarlo antes
de pasar a consulta.
La recepcionista está recibiendo muchas respuestas incomple-
tas o confusas, lo cual dificulta al Dr. Robe el proceso de revisar los
formularios y entender por qué lo visita el nuevo paciente. Además,
las malas respuestas provocan que la recepcionista tarde más tiempo
en introducir los nuevos pacientes en los archivos.
Rediseñe el formulario en papel tamaño carta para poder reco-
lectar los datos pertinentes de una manera lógica e inofensiva.
Asegúrese de que el formulario sea claro para los nuevos pacientes,
fácil de leer para el Dr. Robe y adecuado para que la recepcionista
introduzca los datos en la base de datos de pacientes, ordenada por
nombre del paciente y número de Seguro social. La oficina utiliza
PC conectadas por una LAN. ¿Cómo rediseñaría el formulario de
manera que la recepcionista pudiera enviarlo por vía electrónica?
¿Qué procedimientos de oficina tendría que cambiar?
¿Alguna vez le han realizado cirugía? Sí ____ No____ De ser así, ¿cuándo?______
Describa la cirugía
¿Alguna vez lo han hospitalizado? Sí ____ No____ De ser así, ¿cuándo?______
¿Por qué?
Complete lo siguiente .
He tenido Historial familiar
Diabetes
Problemas cardiacos
Cáncer
Ataques
Desmayos
¿Qué inmunizaciones ha recibido?
Familia: Esposa o familiar directo Relación Dirección
Fecha del último examen ___/___ ¿Quién lo refirió?
¿Por qué está visitando al doctor hoy?
¿Sufre de dolor en este momento?_______ Constante ______ Esporádico ______
¿Cuánto tiempo dura? Escriba su número de seguro social:
¡IMPORTANTE! Necesitamos el número correcto de su compañía de seguros
Formulario de historial médico
Nombre Empleador Edad
Dirección CP Teléfono Oficina
Aseguradora Es esta [ ] su póliza [ ] la póliza de su esposa
Cruz azul [ ] Servicio médico estatal [ ] Otro [ ] (explique)
FIGURA 12.C1
Se aprecia de manera considerable su ayuda para mejorar este formulario.www.xlibros.com

378 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
La tercera sección de la pantalla es de “comentarios e instrucciones”, y puede mostrar un menú corto de co-
mandos que recuerdan al usuario aspectos básicos como cambiar de página, funciones y acciones como guardar
el archivo o terminar de introducir datos. Al incluir dichos aspectos básicos los usuarios inexpertos se sienten
mucho más seguros sobre su capacidad para completar la tarea.
Otras maneras de mantener simple la pantalla es utilizar ayuda sensible al contexto, botones desplegables
que revelen más información y otras ventanas desplegables. Los usuarios pueden minimizar o maximizar el ta-
maño de las ventanas según sea necesario. De esta manera, los usuarios empiezan con una pantalla simple y bien
diseñada que pueden personalizar y controlar por medio de varias ventanas. Los hipervínculos en un formulario
basado en Web sirven para un propósito similar.
Mantener la pantalla consistente
El segundo lineamiento para el buen diseño de pantallas es mantener la pantalla consistente. Si los usuarios
trabajan con formularios en papel, las pantallas deben seguir lo que se muestra en papel. Podemos mantener la
consistencia en las pantallas si ubicamos la información en la misma área cada vez que se acceda a una nueva
pantalla. Además, la información que debe estar junta por lógica también se debe agrupar en forma consistente:
el nombre y la dirección van juntos, pero no el nombre y el código postal. Aunque la pantalla debería tener un
movimiento natural de una región a otra, la información no se debe traslapar de un grupo a otro. No es conve-
niente tener el nombre y la dirección en un área y el código postal en otra.
Facilitar el movimiento
El tercer lineamiento para el buen diseño de pantallas es facilitar el proceso de pasar de una página a otra. La
regla de los “tres clics” establece que los usuarios deben ser capaces de llegar a las páginas que necesitan en tres
clics de ratón o de teclado como máximo. Los formularios basados en Web facilitan el movimiento mediante el
uso de hipervínculos a otras páginas Web relevantes. Otro método común de movimiento es hacer que los usua-
rios se sientan como si estuvieran cambiando físicamente a una nueva página. Esta ilusión de movimiento físico
entre pantallas se puede obtener al desplazarse mediante flechas, ventanas desplegables sensibles al contexto o
un cuadro de diálogo en pantalla.
Diseñar una pantalla atractiva y agradable
El cuarto lineamiento para el buen diseño de pantallas es crear una pantalla atractiva para el usuario. Si los usua-
rios encuentran que las pantallas son agradables, es probable que sean más productivos, necesiten menos super-
visión y cometan menos errores. Las pantallas deben atraer a los usuarios y mantener su atención. Para lograr
este objetivo se utilizan muchas áreas en blanco que rodean a los campos de entrada de datos, de manera que
la pantalla adquiera una apariencia ordenada. Nunca hay que atiborrar un formulario de información; de igual
forma, nunca hay que atiborrar una pantalla. Es mucho mejor usar varias ventanas o hipervínculos que tratar de
meter todo a la fuerza en una sola página.
Use flujos lógicos en el plan para las páginas que desea visualizar. Organice el material para aprovechar la
forma en que las personas conceptualizan su trabajo, de manera que puedan desplazarse con facilidad por la in-
formación. Con la llegada de las GUI, es posible crear pantallas de entrada muy atractivas. Mediante el uso de
color o cuadros sombreados y la creación de cuadros y flechas en tercera dimensión, es posible crear formularios
amigables y divertidos.
Al considerar el uso de distintos estilos y tamaños de letras, pregúntese si realmente ayudan a que el usua-
rio comprenda cómo usar la pantalla y que la apruebe. Si atraen demasiada atención hacia el aspecto visual de
la pantalla o si sirven como distracción, omítalas. Tenga en cuenta que no todas las páginas Web se ven exacta-
mente igual en todos los navegadores. Pruebe los prototipos de sus formularios con una variedad de combinacio-
nes para ver si los usuarios declaran sus preferencias por ciertas combinaciones o si son molestas para la mayoría
de ellos. Para las fuentes Web use Verdana o Arial.
Utilice iconos en el diseño de las pantallas
Los iconos son representaciones pictóricas en pantalla que simbolizan las acciones de computadora que los
usuarios pueden seleccionar mediante el uso de ratón, teclado, lápiz óptico, pantalla táctil o palanca de juegos.
Los iconos tienen funciones similares a las de las palabras y pueden reemplazarlas en muchos menús, ya que su
significado se comprende con mayor rapidez. Los dispositivos móviles como el iPhone y el iPod de Apple han
popularizado el uso de iconos en las pantallas táctiles y han hecho de esta interfaz algo familiar para muchas
empresas y otros usuarios.
Hay algunos lineamientos para el diseño de iconos efectivos. Las formas deben ser reconocidas de inme-
diato, para que el usuario no tenga que dominar un nuevo vocabulario. Hay varios iconos que la mayoría de los
usuarios ya conoce. El uso de iconos estándar puede explotar rápidamente esta reserva de significado común.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 379
Apellido paterno del paciente Primer nombre Inicial segundo nombre
Estación de inspección Fecha del examen
Número de paciente Número de seguro social
Primer examen Número de reclamación
SECCIÓN DE AUDIOMETRÍA VOCAL Comentarios [
UMBRAL DE RECEPCIÓN DE VOZ
Oído derecho [ ]
Oído izquierdo [ ] Referido por [ ]
DISCR. OÍDO DERECHO. Motivo de referencia
% [ ] Enmascaramiento [ ]
% [ ] Enmascaramiento [ ]
Audiólogo examinador
DISCRIM. OÍDO IZQUIERDO Número de audiólogo examinador
Siguiente solicitante
INFORME DEL EXAMEN AUDIOLÓGICO
CONDUCCIÓN DE AIRE
CONDUCCIÓN ÓSEA
500 1000 2000 4000 6000
Oído derecho
500 1000 2000 4000 6000
Oído izquierdo
500 1000 2000 4000 6000
Oído derecho
500 1000 2000 4000 6000
Oído izquierdo
FIGURA 12.C2
Esta pantalla se puede diseñar de manera que sea más amigable para el usuario.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 2 . 2
Tener todo junto no siempre es lo mejor
El departamento de Audiología en un extenso hospital de veteranos
utiliza una PC y un monitor para que los técnicos de audiología pue-
dan introducir datos directamente en el sistema de registros de pa-
cientes. Después de hablar con Earl Lobes, uno de los técnicos, usted
determina que el diseño de la pantalla es un problema importante.
“Utilizamos un formulario una vez y funcionó”, dice el Sr.
Lobes. “Sin embargo, la pantalla no tiene sentido. Creo que tuvie-
ron que meter todo a la fuerza ahí, y eso lo arruinó”.
A usted le han pedido que rediseñe la pantalla (vea la figura
12.C2 ) para capturar la misma información, pero hay que simplifi-
carla, ya que al hacerlo se reducen los errores que han estado aco-
sando a los técnicos. Usted se da cuenta que meter toda la información
en una sola pantalla no es el único problema.
Explique sus motivos para cambiar la pantalla de la forma en
que lo hizo. Puede usar más de una página de visualización si lo
considera necesario.
Un usuario puede apuntar a un archivero, “sacar” un icono de carpeta, “agarrar” una pieza de icono de papel y
“echarla” al icono de bote de basura. Al emplear iconos estándar, los diseñadores y usuarios ahorran tiempo.
Los iconos para una aplicación específica deben estar limitados a una cantidad aproximada de 20 formas
reconocibles, de manera que el vocabulario de iconos no sea tan abrumador y se pueda realizar un esquema de
codificación que valga la pena. Use iconos de manera consistente en las aplicaciones donde aparecerán juntos
para asegurar la continuidad y facilidad de comprensión. En general, los iconos valen la pena para los usuarios si
son significativos.
Diseño de la interfaz gráfica de usuario
Una interfaz gráfica de usuario (GUI) es la forma en que los usuarios interactúan con los sistemas operativos
Windows y Macintosh. Esto también se conoce como interfaz de apuntar y hacer clic (point-and-click). Los
usuarios pueden usar un ratón para hacer clic en un objeto y arrastrarlo hasta una posición específica. Las interfa-www.xlibros.com

380 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
ces gráficas de usuario aprovechan las características adicionales en el diseño de pantallas, como los cuadros de
texto, las casillas de verificación, los botones de opción, los cuadros de lista y de lista desplegable, los controles
deslizantes y botones aumentar/disminuir, los cuadros de diálogo con controles en pestañas y los mapas de ima-
gen. La figura 12.4 es una pantalla de entrada de Microsoft Access que muestra varios controles de GUI.
CUADROS DE TEXTO Un rectángulo representa un cuadro de texto, como vimos antes; se utiliza para delinear
los campos de entrada y visualización de datos. Hay que tener cuidado de asegurar que el cuadro de texto sea lo
bastante grande como para poder alojar todos los caracteres que es necesario introducir. Cada cuadro de texto
debe tener una leyenda a la izquierda para identificar lo que se va a introducir o lo que se muestra en el cuadro.
En Microsoft Access, los datos de caracteres se alinean a la izquierda y los datos numéricos a la derecha.
CASILLAS DE VERIFICACIÓN En el ejemplo de los controles de GUI se utiliza una casilla de verificación para
indicar un nuevo cliente. Las casillas de verificación pueden contener una X o estar vacías, lo que corresponde
a indicar si el usuario seleccionó o no la opción; se utilizan para marcar una o más opciones (es decir, en forma
no exclusiva). Una notación alternativa es utilizar un botón cuadrado con una marca de verificación (✓) para
indicar que se seleccionó esa opción. Cabe mencionar que por lo general el texto (o leyenda) de la casilla de
verificación se coloca a la derecha del cuadro. Si hay más de una casilla de verificación, las etiquetas deben tener
cierto orden, ya sea alfabético o que el elemento que se marque con más frecuencia aparezca primero en una
lista. Si hay más de 10 casillas de verificación, agrúpelas en un recuadro.
BOTONES DE OPCIÓN Un círculo conocido como botón de opción se utiliza para seleccionar opciones exclusivas:
se puede elegir sólo una de varias. De esta forma podemos dejar en claro a los usuarios que deben decidir entre
varias. De nuevo, las elecciones se enlistan a la derecha del botón, por lo general en cierta secuencia. Si hay una
opción que se seleccione con frecuencia, por lo general se selecciona como predeterminada la primera vez que se
muestra la página. A menudo hay un rectángulo, conocido como grupo de opciones, que rodea a los botones de
opción. Si hay más de seis botones de opción tal vez sea más conveniente usar un cuadro de lista o un cuadro
de lista desplegable.
CUADROS DE LISTA Y DE LISTA DESPLEGABLE Un cuadro de lista muestra varias opciones que se pueden
seleccionar con el ratón. Un cuadro de lista desplegable se utiliza cuando hay poco espacio disponible en la
página. Un solo rectángulo con una flecha apunta para abajo hacia una línea localizada del lado derecho del
rectángulo. Al seleccionar esta flecha se despliega un cuadro de lista. Una vez que el usuario selecciona un
elemento, se muestra en el rectángulo de selección desplegable y el cuadro de lista desaparece. Si hay una opción
que se seleccione con frecuencia, por lo general se muestra de manera predeterminada en la lista desplegable.
CUADROS DE DIÁLOGO CON CONTROLES EN PESTAÑAS Estos cuadros de diálogo son otra parte de las interfaces
gráficas de usuario y otra forma de hacer que los usuarios se organicen y comprendan el material del sistema con
eficiencia. Al diseñar los cuadros con controles en pestañas, cree una pestaña separada para cada característica
única, coloque las pestañas que se utilizan con más frecuencia al frente y muéstrelas primero; incluya también
botones para Aceptar, Cancelar y Ayuda.
FIGURA 12.4
El diseñador tiene muchos
componentes de GUI que permiten
flexibilidad al diseñar pantallas de
entrada para la Web u otros
paquetes de software. Este
ejemplo es de Microsoft Access.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 381
CONTROLES DESLIZABLES Y BOTONES AUMENTAR/DISMINUIR Estos controles se utilizan para cambiar los datos
que tienen un rango continuo de valores; proporcionan mayor control a los usuarios en su tarea de seleccionar
valores. Al desplazar el control deslizable en una dirección o en otra (ya sea izquierda/derecha o arriba/abajo)
los valores aumentan o disminuyen. La figura 12.5 muestra el uso de controles deslizables para cambiar la cantidad
de rojo (Red), verde (Green) y azul (Blue) al seleccionar un nuevo color. Los botones aumentar/disminuir
también se utilizan para cambiar un valor continuo y se muestran a la derecha de los controles deslizables.
MAPAS DE IMAGEN Los campos de los mapas de imagen se utilizan para seleccionar valores dentro de una
imagen. El usuario hace clic en un punto dentro de una imagen y se envían las correspondientes coordenadas x
y y al programa. Los mapas de imagen se utilizan al crear páginas Web que contienen mapas con instrucciones
para hacer clic en cierta área y poder ver un mapa detallado de la región.
ÁREAS DE TEXTO Un área de texto se utiliza para introducir una cantidad mayor de texto. Estas áreas incluyen
varias filas, columnas y barras de desplazamiento que permiten al usuario introducir y ver texto que sea mayor
que el tamaño del área del cuadro. Hay dos formas de manejar este texto. Una es evitar el uso del ajuste de línea, que
obliga al usuario a oprimir la tecla Intro para pasar a la siguiente línea; el texto se desplazará a la derecha si
excede la anchura del área de texto. La otra opción es permitir el ajuste de línea.
CUADROS DE MENSAJE Los cuadros de mensaje se utilizan para advertir a los usuarios y proveer otros mensajes
de retroalimentación en un cuadro de diálogo, traslapando con frecuencia la pantalla. Estos cuadros de
mensaje tienen distintos formatos. Cada uno debe aparecer en una ventana rectangular y debe redactar con
claridad el mensaje, de manera que el usuario sepa precisamente lo que está ocurriendo y qué acciones se pueden
tomar.
BOTONES DE COMANDOS Un botón de comando realiza una acción cuando el usuario lo selecciona con el ratón.
Calcular el total, Agregar pedido y Aceptar son algunos ejemplos. El texto se centra en el botón, que tiene una
forma rectangular. Si hay una acción predeterminada, el texto se rodea con una línea punteada. El botón también
se puede sombrear para indicar que es el predeterminado. Los usuarios oprimen Intro para seleccionar el botón
predeterminado.
Controles y valores de los formularios
Cada uno de los controles incluidos en una interfaz de GUI deben tener alguna forma de almacenar los datos aso-
ciados con el control. En una página Web se utiliza un par de nombre y valor, los cuales se transmiten al servidor
o se envían en un correo electrónico junto con el formulario, como un nombre de ciudad y un valor de Paris, por
ejemplo. El nombre está definido en el formulario de la página Web y el software del servidor debe reconocer ese
nombre para entender lo que debe hacer con el valor o los datos que se envían con el formulario Web.
La forma en que se obtiene el valor es distinta para cada control del formulario Web. En los cuadros de texto
o en las áreas de texto, el valor consiste en los caracteres tecleados en los cuadros. En los botones de opción y las
casillas de verificación, el texto que aparece a la derecha de cada botón de opción o casilla de verificación es para
uso humano solamente. El valor se define en el formulario Web y se transmite al momento de enviar el formulario.
Si se utilizan estos datos para actualizar una base de datos, a menudo los valores son códigos que se envían y des-
pués se almacenan en el servidor, y el analista debe decidir cuáles deben ser los valores apropiados al hacer clic en
cada botón de opción o casilla de verificación. Las listas desplegables son algo distintas de los botones de opción o
las casillas de verificación en cuanto a que hay muchas opciones para una lista desplegable específica. Es necesario
FIGURA 12.5
Los controles deslizantes y
botones aumentar/disminuir son
dos componentes de GUI
adicionales que el analista
puede utilizar para diseñar
pantallas de entrada.www.xlibros.com

382 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 12.6
Un formulario de entrada basado
en Web para que los usuarios se
registren en un crucero.
decidir los valores para cada una de las opciones de la lista desplegable y, al elegir una opción, el valor seleccionado
se envía con el formulario. Los valores de los formularios también se pueden usar en cálculos mediante el uso de
JavaScript en el navegador. Éstos se pueden usar para multiplicar, sumar y tomar decisiones.
La figura 12.6 es un ejemplo de un formulario utilizado para obtener precios y registrarse en un crucero. El
texto en las áreas Nombre (Name), Dirección (Address), Ciudad (City), Estado (State), Código postal (Zip), Te-
léfono (Phone) y Email se envía al servidor junto con el formulario. Se puede seleccionar sólo uno de los botones
de opción para el crucero de 4 días (4-day), 7 días (7-day) o 15 días (15-day). Los valores enviados son S de
corto (short), en caso de que se seleccione el crucero de 4 días, A para indicar una longitud promedio (average)
en caso de que se seleccione la opción de 7 días y L para un crucero largo (long) si se selecciona el de 14 días.
Además, al seleccionar uno de estos cruceros se inserta la cantidad en dólares en uno de los cuadros de texto del
lado izquierdo del formulario Web, y se borra cualquier botón de opción seleccionado antes, junto con cualquier
cantidad. Si se marca la casilla de verificación para el cuarto con vista al océano (ocean side room), se transmite
al servidor un valor de Y para indicar Sí, se inserta la cantidad en el cuadro de texto del lado izquierdo y se ac-
tualiza el total. Si el cliente trata de cambiar las cantidades en los cuadros de texto calculados, se reinician. Al
hacer clic en el botón Enviar (Submit), se envían las cantidades al servidor junto con los demás datos.
Campos ocultos
Otro de los tipos de controles que se encuentran en los formularios Web es el campo oculto. Estos controles no
son visibles para el espectador, no ocupan espacio en la página Web y pueden contener sólo un nombre y un
valor. Con frecuencia los campos ocultos se utilizan para almacenar los valores que se envían de un formulario
Web al servidor. Generalmente se requiere incluir estos valores en un segundo formulario cuando se requieren
formularios múltiples para capturar todos los datos de la transacción. Algunas veces se utilizan para retener
información sobre el tipo de navegador que se utiliza, el sistema operativo del usuario que está navegando, et-
cétera. Algunas veces un campo oculto contiene un campo clave que se utiliza para localizar un registro para el
cliente o la sesión de exploración.
Tablas de respuesta a eventos
Cuando hay interacciones complicadas en un formulario Web (o en cualquier otro formulario de GUI), podemos
utilizar una tabla de respuesta a eventos para hacer una lista de la variedad de eventos que pueden ocurrir. Po-
demos usar estas tablas de respuesta a eventos en un nivel alto para modelar los eventos y las respuestas de la
empresa (lo que vimos en el capítulo 7), pero, en general, los eventos que ocurren en un formulario Web o en
otra pantalla se limitan a las acciones de los usuarios. Estos eventos pueden ser un clic en un botón, cambiar un
valor, enfocar el campo (mover el cursor dentro del campo o en un botón de opción, casilla de verificación u otro
control), quitar el foco de un campo (el usuario mueve el cursor hacia fuera del campo), cargar la página Web,
detectar las pulsaciones de teclas y muchos otros eventos. La respuesta muestra una lista de cómo debe reaccio-www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 383
nar la página Web cuando ocurra el evento. Los eventos son para un objeto específico, como un botón, un campo
de texto, toda la página Web, etcétera.
La figura 12.7 muestra un sitio Web en el que es posible estimar el costo de la estancia en el Azure Islé
Resort. El usuario puede introducir el número de huéspedes, cambiar las fechas de inicio y final, e introducir el
número de personas para varias actividades adicionales, como buceo o golf.
En la figura 12.8 se muestra la tabla de respuesta a eventos. Observe que puede haber varios eventos para cada
control del formulario Web. Como el usuario puede realizar cualquier número de acciones y en cualquier orden, la
tabla de respuesta a eventos es útil para mostrar lo que debería ocurrir. Por ejemplo, el usuario puede hacer clic en
el botón Calcular (Calculate) primero, cambiar las fechas de inicio y final o cambiar el número de personas. La ta-
bla de respuesta a eventos también es útil para construir un formulario Web que requiera un mínimo de acción por
parte del usuario. Por ejemplo podemos considerar cuando el usuario cambia el mes o día de inicio: el mes o día
final cambia para coincidir con el mes o día inicial. El año cambia cuando el mes es anterior al mes en curso, ya que
las personas no se pueden quedar en un centro vacacional antes del día actual en el mismo año.
Algunas veces podemos usar la tabla de respuesta a eventos para explorar las mejoras en la página Web. Su-
ponga que Azure Islé Resort determinó que la mayoría de sus clientes se quedaron durante siete días. Al cambiar
el mes o día inicial, la fecha final se podría establecer de manera predeterminada en siete días. También podría
ser conveniente tener botones de opción que permitieran al cliente seleccionar una estadía de 4, 7 o 14 días y calcular
la fecha final. Otra mejora a una página Web podría ser detectar cuando se haya introducido cierto número de ca-
racteres, por ejemplo los tres dígitos que corresponden al código de área de un teléfono de Estados Unidos, para
después mover el cursor hacia el siguiente campo.
Los eventos no se limitan al trabajo dentro de una sola página Web; también se pueden usar para controlar
la navegación entre páginas. Esto puede ocurrir al momento de cambiar una selección en una lista desplegable o
al hacer clic en un botón de opción. Los eventos también se pueden usar para cambiar el contenido de las listas
desplegables. Por ejemplo, en una página para buscar empleo, al seleccionar una categoría de empleo pueden
aparecer las posiciones detalladas para ese empleo en una segunda lista desplegable.
Páginas Web dinámicas
Las páginas Web dinámicas cambian por sí solas como resultado de la acción de los usuarios. A menudo utili-
zan JavaScript para modificar cierta parte de la página Web o un estilo. Cambiar una imagen cuando el ratón
se desplaza sobre ella o girar imágenes aleatorias en un intervalo de tiempo establecido son ejemplos comunes
de páginas Web dinámicas. La página Web puede detectar la anchura de la ventana del navegador y modificar
la página en concordancia. Los menús que se expanden cuando el usuario hace clic en un pequeño signo po-
sitivo a la izquierda del menú o cuando desplaza el ratón sobre un menú son otros ejemplos de páginas Web
dinámicas.
El poder de las páginas Web dinámicas se ha expandido de manera considerable en los navegadores Web re-
cientes. Mediante el uso de JavaScript, un formulario Web puede transformarse a sí mismo para agregar nuevos
FIGURA 12.7
Un sitio Web que permite a los
usuarios estimar el costo de la
estancia en el Azure Islé Resort,
que cambia dependiendo del
número de huéspedes, la duración
y las actividades adicionales.www.xlibros.com

384 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Control del formulario Evento Respuesta
Página Web La página se carga Colocar el año actual en los campos Año inicial (Starting Year) y Año final (Ending
Year). Colocar el cursor en el campo Número de personas (Number of People).
Número de personas Cambia el valor Verificar que Número de personas contenga un número mayor que cero.
Mes inicial
(Starting Month)
Cambia la
selección
Establecer el Mes final (Ending Month) en la lista desplegable al valor del Mes
inicial. Si el mes es menor que el mes actual, cambiar los valores de Año
inicial y Año final al siguiente año..
Día inicial
(Starting Day)
Cambia la
selección
Establecer el Día final (Ending Day) en la lista desplegable al Día inicial. Use
el valor de Mes inicial para establecer los valores de Año inicial y Año final.
Año inicial Recibe el enfoque Use el valor Mes inicial para calcular los valores de Año inicial y Año final.
Número de días
(Number of Days)
Recibe el enfoque;
cambia el valor
Calcular el Número de días que se quedará el cliente. Si el número es menor
o igual a cero, mostrar un mensaje de error.
Cargo básico
(Basic Charge)
Recibe el enfoque Calcular el Cargo básico y colocar el cursor en el campo Número de personas
para la aventura de buceo (Scuba Adventure Number of People).
Número de personas para
la aventura de buceo
Recibe el enfoque Seleccionar la cantidad actual mostrada (cero) de manera que el cliente pueda
reemplazarla.
Número de personas para
la aventura de buceo
Cambia el valor Calcular el Costo de buceo (Scuba Cost) con base en el valor de Número de
personas para la aventura de buceo y colocar el cursor en el campo Número
de personas para golf (Golf Number of People).
Costo de buceo Cambia el valor Recalcular el Costo de buceo y colocar el cursor en el campo Número de
personas para golf.
Número de personas
para golf
Recibe el enfoque Seleccionar la cantidad actual mostrada (cero) de manera que el cliente pueda
reemplazarla.
Número de personas
para golf
Cambia el valor Calcular el Costo de golf y colocar el cursor en el campo Número de personas
para montar a caballo (Horseback Riding Number of People).
Costo de golf Cambia el valor Recalcular el Costo de golf y colocar el cursor en el campo Número de
personas para montar a caballo.
Número de personas
para montar a caballo
Recibe el enfoque Seleccionar la cantidad actual mostrada (cero) de manera que el cliente pueda
reemplazarla.
Número de personas
para montar a caballo
Cambia el valor Calcular el Costo de montar a caballo (Horse Riding Cost) con base en el valor
de Número de personas para montar a caballo y colocar el cursor en el
campo Apellido paterno (Last Name).
Costo de montar
a caballo
Cambia el valor Recalcular el Costo de montar a caballo y colocar el cursor en el campo
Apellido paterno.
Costo total (Total Cost) Cambia el valor Calcular el costo total y colocar el cursor en el campo Apellido paterno.
Botón Calcular
(Calculate)
Se hizo clic en el botón Validar los datos del formulario y mostrar un mensaje de error en caso de que
ocurra algún error. Calcular el Costo total si no hay errores.
Botón Restablecer
(Reset)
Se hizo clic en el botón Borrar el formulario y colocar el año actual en los campos Año inicial y Año final.
Colocar el cursor en el campo Número de personas (Number of People).
Botón Imprimir (Print) Se hizo clic en el botón Validar los datos del formulario y mostrar un mensaje de error en caso de que
ocurra algún error. Calcular el Costo total si no hay errores. Usar una cookie
en el sitio Web para pasar los datos a una página de confirmación que no
permita a los usuarios modificar los datos.
Botón Enviar
(Submit)
Se hizo clic en el botón Validar los datos del formulario y mostrar un mensaje de error en caso de que
ocurra algún error. Calcular el Costo total si no hay errores. Enviar el
formulario al servidor y enviar la confirmación al usuario.
FIGURA 12.8
Una tabla de respuesta a eventos que muestra la lista de controles del formulario, eventos y respuestas para varios eventos que pueden ocurrir
cuando el usuario interactúa con la pantalla para estimar costos de Azure Islé Resort.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 385
campos o eliminar campos antiguos, o para cambiar los atributos de los campos, como la longitud de un campo
o convertir un botón de opción en una casilla de verificación. Esto hace que la página Web sea más sensible a las
acciones de los usuarios y a menudo elimina la necesidad de cargar nuevas páginas Web con base en las eleccio-
nes de los usuarios.
El analista debe pensar en la información que tendría sentido para el usuario del sitio Web. Por ejemplo, al
colocar la lista de selección de país en una página Web antes de otros elementos de la dirección el usuario puede
cambiar la lista de países para que cambien a su vez las leyendas y se refleje el país. Si la persona seleccionó
Estados Unidos de la lista desplegable, las leyendas dirían ‘Estado’ y ‘Zip Code’. Si el país fuera Canadá, las le-
yendas dirían ‘Provincia’ y ‘Código postal’. Si fuera Japón, sería ‘Prefectura’ y ‘Código de correo’.
Páginas Web tridimensionales
Las páginas Web dinámicas también se pueden usar para mostrar información de manera temporal, como un
bloque de información de ayuda, un calendario con fechas en las que se pueda hacer clic para ayudar con los
campos para introducir fechas, los códigos de aeropuertos y demás información relacionada. Esta información se
puede almacenar mediante el uso de una serie de capas apiladas (que utilizan la propiedad de índice z de estilos
en cascada) en el diseño de la página Web, cada una encima de la otra. La página Web principal es el plano base,
la capa estándar de la página Web que muestra u obtiene información, mientras que las otras capas debajo de la
página no son visibles.
Cuando se solicita ayuda o el usuario hace clic en el campo de la fecha, la capa se desplaza a la parte supe-
rior y se hace visible, o se genera mediante código de JavaScript y aparece. El analista o diseñador determina la
posición de la capa, como un calendario que aparece a la derecha de un campo de fecha. Al seleccionar una fecha
se hace clic en un vínculo para cerrar o el usuario hace clic fuera del calendario y la capa se vuelve a colocar
debajo de la superficie de la página Web o se elimina. El analista debe determinar si sería conveniente incluir
información adicional para asegurar que la información sea precisa y que haya una buena comunicación con el
usuario.
El analista debe determinar lo siguiente:
1. ¿Cómo se construyó la capa? ¿Se creó mediante el uso de código JavaScript, como un calendario, o se
requiere información adicional para construir la capa? Si se requiere información adicional, ¿dónde se
encuentran los datos y cómo se deben obtener? Lo ideal es que la información se obtenga de una sola tabla
de la base de datos en el servidor, mediante el uso de tecnologías Ajax.
2. ¿Qué eventos provocaron que se creara la capa? Estos incluyen el que un usuario haga clic o seleccione
una pestaña para llegar a un campo, o contar el número de pulsaciones de tecla introducidas en un campo.
Un ejemplo sería una cadena de hoteles con muchas ubicaciones: si se incluyeran todas en una lista
desplegable, ésta sería demasiado larga. Entonces, cuando el usuario introduce tres caracteres, aparece un
bloque en el que se muestra una lista de los hoteles que empiezan con esas tres letras, incluyendo el país,
ciudad, estado o provincia y demás información. Si se hubiera configurado el evento de detectar sólo dos
letras, la lista presentada hubiera sido demasiado larga para el bloque de visualización.
3. ¿Qué elementos eliminan la capa, como un botón para cerrar, hacer clic en una fecha, hacer clic fuera
de la región o seleccionar un hotel de la lista?
4. ¿Dónde se debe colocar el bloque que aparezca? Por lo general, enseguida del campo que creó el bloque,
en coordenadas x y y.
5. ¿Qué tan grande debe ser el bloque, medido en píxeles? Si la información es demasiado extensa para el
bloque, como una lista de hoteles, el analista debe decidir cómo manejar la información adicional. Las
opciones incluyen agregar barras de desplazamiento o colocar un vínculo a la siguiente página de
información en la parte inferior.
6. ¿Cuáles deben ser los atributos de formato de región, como color y borde? Si hay una serie de vínculos,
revise su apariencia con los usuarios. Pregúnteles si quisieran que cambiara el color al desplazar el ratón
sobre cada fila.
7. ¿Qué debe ocurrir al seleccionar una opción? En el caso de un calendario de reservaciones, al hacer clic en
una fecha ésta se coloca en la fecha inicial. Si se selecciona un hotel, la ciudad, estado o provincia, junto
con la información del país y un vínculo al hotel, deberán llenar los campos del formulario Web.
El uso de capas constituye una forma efectiva de construir sitios Web, ya que no se requieren páginas pop-up
(que el software de seguridad de Internet podría bloquear). Además, una página Web nueva no se tiene que cargar
y, como la información está contenida en una capa, no ocupa espacio en la página Web principal.
La figura 12.9 es un ejemplo de un formulario Web utilizado por una compañía de seguros para cambiar la
información de los clientes; agregar una nueva ubicación para un cliente, como una nueva tienda o restaurantewww.xlibros.com

386 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Si se hace clic en “Agregar
nueva propiedad (Add New
Property)”, aparece un
nuevo cuadro de propiedad
del asegurado.
Si se selecciona
“Corporativo (Corporate)”,
la página cambia para
mostrar un campo para
“Compañía (Company)”.
FIGURA 12.9
Ejemplo de una página Web
dinámica de una compañía de
seguros. Si el usuario hace clic
en “Agregar nueva propiedad
(Add New Property)”, aparece
un cuadro de nueva propiedad
para el asegurado.
para un cliente existente; o eliminar una tienda para el cliente. Si está seleccionada la casilla de verificación Cor-
porativo (Corporate), los campos Apellido paterno (Last Name), Primer nombre (First Name) y Segundo
nombre (Middle) cambian a un campo de nombre Compañía (Company), y también cambia el texto de las
leyendas. Si se hace clic en el botón Agregar nueva propiedad (Add New Property), se agrega un nuevo con-
junto de campos para la tercera propiedad. Hay que tener cuidado de generar nombres únicos que el servidor re-
conocerá para los campos adicionales. Al enviar el formulario, el servidor actualiza las tablas de la base de datos
para agregar los campos adicionales.
El analista debe decidir cuándo es apropiado el uso de páginas Web dinámicas. Si los datos cambian al cam-
biar otras partes de la página Web (como hacer clic en un botón de opción o seleccionar un elemento de una lista
desplegable), puede ser buena política diseñar las páginas Web como un formulario dinámico. Pero si algunas
partes del formulario Web no están seguras y otras partes requieren de cifrado, probablemente sea mejor no usar
formularios dinámicos.
En Expedia.com (www.expedia.com) encontrará un buen ejemplo de un formulario que se modifica a sí
mismo. Al hacer clic en los botones de opción para un vuelo, hotel, auto o crucero, el formulario cambia para
recopilar los datos apropiados para reservar un vuelo o un hotel, por ejemplo.
Las páginas Web dinámicas tienen la ventaja de que se modifican a sí mismas con rapidez, con menos in-
terrupciones para enviar y recibir datos del servidor. Sin embargo, presentan ciertas desventajas; una de ellas es
que no funcionan si se desactiva el JavaScript. El analista debe decidir qué hacer en esta situación.
Si la persona debe usar el sitio Web (como en un entorno de intranet corporativo, en un sitio utilizado para
obtener préstamos para estudiantes, o en el caso de procesar transacciones gubernamentales o de otro tipo), la pá-www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 387
gina Web puede establecer con claridad que no funcionará si se desactiva JavaScript y después indicar al usuario
cómo activarlo. La mayoría de los sitios Web comerciales no requieren que JavaScript esté activado y contarán
con un sitio Web alternativo para los clientes.
Una segunda desventaja al usar páginas Web dinámicas es que tal vez no cumplan con la Ley sobre estado-
unidenses con discapacidades (para obtener más información sobre la accesibilidad Web para todos los usuarios,
consulte el capítulo 14 sobre el diseño de la interacción humano-computadora).
Ajax (JavaScript asíncrono y XML)
Ajax es una técnica que funciona en los navegadores Web más recientes. Implica el uso de JavaScript y el
lenguaje de marcado extensible (XML). Antes de Ajax, cada vez que una página Web necesitaba datos de
una tabla distinta de la base de datos, se enviaba una petición al servidor y se cargaba toda una nueva página
completa. Esto es efectivo pero lento, ya que debemos cargar una página completa sólo para proveer datos
adicionales para una lista desplegable o algún otro control de formulario Web con base en lo que se seleccionó
antes.
Ajax permite a los desarrolladores Web construir una página Web que funcione en forma más parecida a un
programa de escritorio tradicional. A medida que se necesitan nuevos datos, el navegador envía una petición al
servidor y éste devuelve una pequeña cantidad de datos al navegador, quien a su vez actualiza la página actual.
Esto significa que el espectador no experimenta una interrupción en su trabajo y la página Web no se vuelve a
cargar. La página se actualiza en forma dinámica con los nuevos datos.
Estos datos pueden ser un pequeño archivo de texto o un documento de XML que contenga muchos clientes
u otros datos repetitivos. Si los datos están en un archivo de XML, a cada elemento cliente se le denomina nodo y
cada nodo se enumera (empezando desde cero) desde el principio del documento de XML. Esto permite a la página
Web ir al primer o último cliente, o iterar por todos los clientes de uno en uno mediante un clic del botón.
Digamos que un analista de sistemas está diseñando un sitio Web tradicional sin Ajax, para hacer reserva-
ciones en un trasbordador europeo. El sitio Web resultante podría contener varias páginas: la primera preguntaría
al cliente sobre el origen y el destino del viaje, la fecha planeada y el número de pasajeros. Como los precios se
determinan con base en el número y las edades de los pasajeros, aparecería una segunda página Web para pre-
guntar edades. Una tercera página preguntaría el tipo de vehículo deseado para la transportación terrestre, y así
sucesivamente.
Podemos obtener la misma información mediante el uso de técnicas Ajax, como se muestra en la figura
12.10. Se introducen los mismos destinos inicial y final, junto con las fechas, en la parte superior del formulario
Web. La página Web utiliza los destinos y las fechas para determinar si hay espacio disponible en el transbor-
dador. Una vez que el cliente modifica el número de pasajeros, el formulario cambia en forma dinámica para
agregar las tres listas desplegables para cada pasajero, junto con las instrucciones a un lado de ellas, y todo sin
tener que recargar toda la página. Cuando cambia el tipo de vehículo, en este caso a Auto (Car), se envía el tipo
de vehículo seleccionado al servidor. La leyenda en el formulario cambia el texto del vehículo a Marca de auto
(Car Make). El servidor envía las posibles marcas de auto y la lista desplegable Marca de auto se llena de da-
tos. Al seleccionar la marca de auto el valor elegido se envía al servidor, se llena la lista desplegable Modelo de
auto (Car Model) y así sucesivamente.
La página Web utilizada en este ejemplo responde mucho más rápidamente que cuando se emplean varias
páginas; además el usuario puede trabajar con más facilidad. De todas formas hay que tener una página Web
de confirmación (aunque la página podría cambiar en forma dinámica para eliminar los campos del formulario
y reemplazarlos con texto) y otra página Web para la información de nombre, dirección y tarjeta de crédito.
El analista debe decidir cómo particionar la transacción en una serie de páginas, para utilizar Ajax en algunas
y en otras no. Si hay que obtener pequeñas cantidades de datos para continuar la transacción y estos datos se
pueden ajustar de manera lógica en un solo formulario o página Web, entonces tal vez Ajax sea el método
más apropiado. A veces es mejor usar varias páginas, como cuando un usuario realiza una reservación en una
aerolínea. Se usa un formulario Web para obtener la información de todos los vuelos y otra página para mos-
trarlos. Se podrá utilizar una tercera página para obtener la información de los pasajeros y una cuarta página
con Ajax para seleccionar las ubicaciones de los asientos, las comidas y demás necesidades individuales para
cada pasajero.
Ajax tiene la ventaja de hacer que la Web funcione con más rapidez y proporciona a los usuarios una
experiencia visual más uniforme. Las desventajas son que JavaScript debe estar habilitado y que la página
Web podría violar la Ley sobre estadounidenses con discapacidades. Hay que tener en cuenta la seguridad en
caso de que sea necesario. Hay muchos ejemplos de sitios Web con Ajax. Algunos notables son Google Earth
(earth.google.com) y Google Suggest, que responde a las pulsaciones de tecla del usuario y provee una lista
desplegable de los posibles términos de búsqueda. Ajax Write (www.ajaxlaunch.com/ajaxwrite) es un proce-
sador de palabras basado en Web. También hay una hoja de cálculo con Ajax y una herramienta para realizar
bosquejos.www.xlibros.com

388 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Una vez que el cliente
selecciona cuatro
pasajeros, el servidor genera
cuatro listas desplegables.
Después de identificar
a los cuatro pasajeros
aparece una pregunta
sobre un vehículo.
Aparecen más
preguntas hasta que
se completa el
formulario.
FIGURA 12.10
Cuando los analistas utilizan técnicas Ajax, una página Web dinámica responde con más rapidez a la entrada corta del usuario de la que
respondería si se requirieran varias páginas distintas.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 389
Uso de color en el diseño de pantallas
El color es una forma atractiva y comprobada de facilitar a los usuarios las tareas que requieren la entrada de
datos en la computadora. El uso apropiado de color en las pantallas nos permite contrastar el primer plano con
el fondo, resaltar los campos importantes en los formularios, mostrar los errores, resaltar la entrada de código
especial y llamar la atención para muchos otros atributos especiales.
Hay que usar colores de alto contraste para mostrar el primer plano y el fondo, de manera que los usuarios pue-
dan comprender rápidamente lo que se presenta. El color de fondo afecta la percepción del color de primer plano.
Por ejemplo, el verde oscuro tal vez se vea distinto si se quita de un fondo blanco y se coloca en uno amarillo.
Las cinco combinaciones más legibles de letras en primer plano sobre un fondo son (empezando con la com-
binación más legible):
1. Negro sobre amarillo.
2. Verde sobre blanco.
3. Azul sobre blanco.
4. Blanco sobre azul.
5. Amarillo sobre negro.
Las combinaciones menos legibles son rojo sobre verde y azul sobre rojo. Como podemos ver, los colores bri-
llantes se deben usar para el primer plano, y los menos brillantes para el fondo. Los colores con contrastes fuer-
tes se deben asignar primero a los campos que se deben diferenciar; después se pueden asignar otros colores.
Use el color para resaltar los campos importantes en las pantallas. Los campos que son importantes se pue-
den mostrar en colores distintos de los demás. Tenga en cuenta las normas culturales. Por lo general el color rojo
implica peligro, pero “en números rojos” también significa que una empresa está perdiendo dinero. Verde signi-
fica “avanzar” y es un color seguro en los países occidentales.
Si desea cumplir con los lineamientos de accesibilidad Web, tal vez también quiera tener en cuenta que entre
el 8 y el 10 por ciento de los habitantes hombres tienen daltonismo, pero menos del 1 por ciento de las mujeres
sufren de este padecimiento. Use otros indicadores además del color para apoyar a los usuarios en la realización
de sus tareas.
Al igual que con cualquier otra mejora, los diseñadores necesitan cuestionar el valor agregado de usar el color,
ya que se pueden cometer abusos; una heurística conveniente es no más de cuatro colores para los nuevos usuarios y
sólo hasta siete para los usuarios experimentados. Los colores irrelevantes distraen y reducen el desempeño; sin em-
bargo, en muchos casos se ha demostrado que el color facilita el uso en formas muy específicas. El color se debe
considerar una manera importante de contrastar el primer plano y el fondo, resaltar los campos y datos importantes,
señalar los errores y permitir un código de entrada especial.
DISEÑO DE PÁGINAS DE INTRANET E INTERNET
En el capítulo 11 hablamos sobre las nociones elementales del diseño de sitios Web. Hay más sugerencias sobre
el diseño de un buen formulario de llenado por Internet o intranet que debe tener en cuenta ahora que aprendió
sobre algunos de los aspectos elementales del diseño de formularios y pantallas de entrada. En la figura 12.11
se muestra una página de pedidos con un formulario para ilustrar los diversos elementos del buen diseño para la
Web. Estos lineamientos son:
1. Proveer instrucciones claras; los usuarios Web tal vez no estén familiarizados con la terminología técnica.
2. Demostrar una secuencia de entrada lógica para los formularios de llenado, en especial debido a que los
usuarios tal vez tengan que desplazarse a una región de la página que no esté visible en un principio.
3. Usar varios cuadros de texto, botones, menús desplegables, casillas de verificación y botones de opción
para funciones específicas y crear interés en el formulario.
4. Proveer un cuadro de texto desplazable si no está seguro sobre cuánto espacio necesitarán los usuarios
para responder a una pregunta, o sobre el lenguaje, la estructura o formulario que utilizarán los usuarios para
introducir los datos.
5. Preparar dos botones básicos en todos los formularios de llenado en Web: Enviar y Borrar formulario.
6. Si el formulario es extenso y los usuarios se deben desplazar con mucha frecuencia, divídalo en varios
formularios más simples en páginas separadas.
7. Crear una pantalla de retroalimentación que se niegue a enviar un formulario a menos que se llenen los
campos obligatorios correctamente. La pantalla del formulario devuelto puede proveer una
retroalimentación detallada para el usuario en un color distinto. Aquí es apropiado el color rojo. Por ejemplo,
tal vez un usuario tenga que escribir el nombre de un país en el campo del país, o necesite indicar un número
de tarjeta de crédito si marcó ese tipo de pago. A menudo un campo obligatorio se indica en una pantalla de
entrada inicial mediante un asterisco de color rojo.www.xlibros.com

390 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U L T O R Í A 1 2 . 3
Juego de máscaras
Al contemplar la actualización del diseño del sitio Web de comer-
cio electrónico para las tiendas Marathon Vitamin, su propietario
Bill Berry se dio cuenta de que sus clientes eran diversos.
“Hemos trabajado duro para atraer muchos tipos de clientes. En
cuanto a la tienda, estamos teniendo éxito. Llegan personas con dis-
tintos intereses. He conocido entusiastas del deporte que desean vita-
minas de alta energía para aumentar su poder. Otros desean perder
peso con la ayuda de los suplementos vitamínicos. Algunos de nues-
tros clientes se preocupan por su salud y creen que tomar vitaminas
diariamente mantiene alejado al doctor. Algunos incluso adoptan el
estilo de vida que se cultivó por primera vez en 1970. Por la forma en
que está configurada la tienda puede ver que estamos tratando de
segmentar el espacio, de manera que los clientes de todo tipo se sien-
tan bienvenidos, aunque es difícil traducir eso a la Web”.
Bill voltea hacia una de sus empleadas, Jin Singh, y le pre-
gunta: “¿Hay algo que podamos hacer para transformar el catálogo
en línea, de manera que atraiga a distintos clientes? ¿Y qué hay
sobre ser receptivo para las distintas personas que visitan el sitio?”.
Jin, que resulta ser fanática de los webcasts en Internet, dice:
“Tengo justo lo ideal”, mientras voltea hacia su computadora y abre su
Windows Media Player. “Personalmente me gusta entrar en un estado
mental que coincida con la música o los videos que veo en la Web”.
Jin muestra a Bill ejemplos de algunas máscaras en la pantalla.
En la figura 12.C3 puede ver varias para Microsoft Windows Media
Player.
Jin continúa: “Las máscaras me permiten personalizar la
apariencia de mi Media Player. Cuando escucho canciones anti-
guas, selecciono una rústica. Cuando voy a escuchar algo de New
Age, opto por una máscara que tenga un arcoíris de colores, por
ejemplo”.
Mientras mira la pantalla, Bill exclama: “Creo que estás en lo
correcto. ¿Cómo dijiste que se llamaban esas cosas?”.
Jin ríe y le explica: “Se llaman máscaras, pero sólo son reves-
timientos divertidos que los clientes pueden agregar a lo que deseen
ver. Puedo prever que en un momento dado el sitio Web podrá asu-
mir una apariencia completamente nueva, dependiendo de las pre-
ferencias de usuario para un tipo específico de máscara”.
Con base en su evaluación de los distintos tipos de clientes que
a Marathon le gustaría atraer a su sitio Web, diseñe, dibuje y des-
criba una serie de máscaras que serían apropiadas para los propósi-
tos de la compañía. Explique en dos párrafos cómo la acción de
incluir máscaras controladas por los usuarios en un sitio Web puede
ampliar los objetivos de diseño del analista en cuanto al atractivo y
la facilidad de uso para la entrada.
FIGURA 12.C3
Seis máscaras de Microsoft Windows Media Player permiten a los usuarios personalizar sus reproductores para adaptarse a su
humor.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 391
Las aplicaciones de comercio electrónico requieren algo más que sólo un buen diseño de sitios Web. Los
clientes necesitan sentirse con la confianza de que van a comprar la cantidad correcta, de que van a obtener el
precio correcto y de que el costo total de una compra por Internet, incluyendo los cargos de envío, sea lo que
esperan. La forma más común de establecer esta confianza es mediante el uso de la metáfora de un carrito o ca-
nasta de compras. La figura 12.12 muestra el contenido de un carrito de compras para un cliente que va a realizar
una compra. Una característica importante del carrito de compras es que el cliente puede editar la cantidad del
artículo que se pide, o lo puede eliminar por completo.
Las aplicaciones de comercio electrónico imponen demandas adicionales para el analista que debe diseñar
sitios Web para cumplir con varios objetivos de usuarios y de negocios, incluyendo establecer la misión y los va-
lores corporativos en relación con la confidencialidad, preservar la privacidad del usuario y obtener devoluciones
rápidas y sencillas; el procesamiento eficiente de las transacciones y la creación de buenas relaciones con los
clientes.
FIGURA 12.11
La pantalla de pedidos del sitio
Web Merchants Bay (www.
merchantsbay.com) es un buen
ejemplo de cómo diseñar un
formulario de entrada claro, fácil
de usar y funcional.
FIGURA 12.12
El sitio Web Merchants Bay
(www.merchantsbay.com)
proporciona un buen ejemplo de
un carrito de compras.www.xlibros.com

392 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
A T R A C T I V O D E L A M A C
El comercio electrónico cambió el mundo al pedir a los usuarios que introdujeran sus datos directamente en formularios
de Web; al hacer esto aumentó la precisión de la entrada de información. Aunque esta metodología es eficiente para las
empresas que reciben datos, la labor de teclearlos recae en el cliente. Por fortuna existe software para automatizar ese
proceso, de manera que los usuarios simplemente tienen que hacer un par de clics en vez de tener que escribir largas
cadenas de caracteres alfanuméricos que constituyen sus datos personales, contraseñas y números de tarjetas de crédito.
En una PC, RoboForm de Siber Systems es una buena alternativa. En la Mac, 1 Password por Agile Web Solutions
parece ser el líder actual.
1 Password permite a un usuario automatizar inicios de sesión, completar la información de tarjetas de crédito,
llenar una identidad completa con dirección de calle y correo electrónico, e introducir notas seguras. Al igual que todo
buen programa de contraseñas, 1 Password incluye características importantes como generadores de contraseñas fuer-
tes, tecnología Anti-Phishing y protección integrada contra keyloggers. 1 Password también es una aplicación para el
iPhone y un programa para la Palm, por lo que los usuarios pueden llevar sus contraseñas consigo.
FIGURA 12.MAC
1Password de Agile Web Solutions.
©2006–09 Agile Web Solutions, todos los derechos reservados.
RESUMEN
En este capítulo presentamos los elementos del diseño de en-
trada para formularios, pantallas y formularios de llenado en Web.
La entrada bien diseñada debe cumplir con los objetivos de
efectividad, precisión, facilidad de uso, simpleza, consistencia
y atractivo. Al conocer los distintos elementos de diseño el ana-
lista podrá alcanzar estas metas.
Los cuatro lineamientos de los formularios de entrada
bien diseñados son: 1) hacer que los formularios sean fáciles
de llenar, 2) asegurar que cumplan con el propósito para el
que se diseñaron, 3) diseñarlos para asegurar que se llenen
de manera satisfactoria y 4) mantener los formularios atrac-
tivos.
El diseño de formularios impresos y el de formularios en
pantalla y para llenado en Web se traslapa en muchos puntos im-
portantes, pero hay algunas distinciones. Las pantallas muestran
un cursor que orienta en forma continua al usuario. Las pantallas
a menudo ofrecen asistencia para el proceso de entrada de datos,
mientras que con la excepción de las instrucciones pre-impresas,
puede ser difícil obtener asistencia adicional con un formu-
lario. Los documentos basados en Web tienen capacidades
adicionales, como hipervínculos incrustados, funciones de ayuda
sensibles al contexto y formularios de retroalimentación, para
corregir la entrada antes de su envío final. Es posible agregar
máscaras como una opción para personalizar un sitio Web.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 393
E X P E R I E N C I A D E H Y P E R C A S E ® 1 2
“¿Acaso no es la primavera la estación más hermosa? El ar-
quitecto capturó verdaderamente la esencia del paisaje, ¿no es así?
Es decir, no puedes ir a ningún lado del edificio sin dejar de ver otro
hermoso panorama por esas enormes ventanas. Cuando Snowden
regresó, dio un vistazo a tus pantallas de salida. La buena noticia es
que piensa que sí funcionarán. El proyecto está floreciendo al
igual que las flores y los árboles. Cuando Snowden regrese de Fin-
landia, ¿podrías tener algunas pantallas de entrada listas para de-
mostración? Él no quiere que las cosas se hagan más lentas sólo
porque está fuera del país. Por cierto, el viaje a Singapur fue muy
exitoso. Tal vez MRE tenga presencia mundial algún dia”.
Preguntas de HYPERCASE
1. Use un formulario de diseño en papel, Microsoft Visio o
software de diseño de formularios para diseñar el prototipo de
un formulario en papel que permita capturar la información de
los clientes para la Unidad de capacitación (Training Unit).
2. Pruebe su formulario con tres compañeros de clase; pídales
que lo llenen y redacten una crítica del formulario.
3. Rediseñe su formulario de entrada para reflejar los
comentarios de sus compañeros de clases.
4. Use un formulario de diseño en papel, Microsoft Visio o
software de diseño de formularios para diseñar el prototipo
de un formulario de pantalla que capture la información de
los clientes para la Unidad de capacitación.
5. Pruebe su pantalla de entrada con tres compañeros de clases;
pídales que elaboren una crítica por escrito sobre el diseño de
la pantalla.
6. Rediseñe la pantalla de entrada con base en los comentarios
que reciba. Explique en un párrafo cómo trabajó en cada
comentario.
FIGURA 12.HC1
Puede ver algunas de las pantallas de entrada en HyperCase. Tal vez quiera rediseñar
algunos de los formularios electrónicos.
Los cuatro lineamientos para las pantallas bien diseñadas
son: 1) mantener la pantalla simple, 2) mantener la presentación
de la pantalla consistente, 3) facilitar el movimiento del usua-
rio entre las pantallas y páginas de visualización y 4) crear una
pantalla atractiva y agradable. Muchos elementos de diseño
distintos permiten al analista de sistemas cumplir con estos li-
neamientos.
Es importante que haya un flujo apropiado en los formu-
larios de papel, las pantallas de visualización y los formularios
de llenado en la Web. Los formularios deben agrupar la infor-
mación de manera lógica en siete categorías; las pantallas se
deben dividir en tres secciones principales. Es posible variar las
leyendas en los formularios y las pantallas, al igual que los ti-
pos de letras y los grosores de las líneas que dividen las subca-www.xlibros.com

394 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
tegorías de información. Los formularios de partes múltiples
son otra manera de asegurar que los formularios cumplan con
el propósito para el que fueron diseñados. Los diseñadores
pueden usar ventanas, cuadros desplegables, cuadros de diá-
logo y valores predeterminados en pantalla para asegurar la
efectividad del diseño.
Las tablas de respuesta a eventos ayudan al analista a
documentar lo que debería ocurrir al momento en que ocu-
rren los eventos. Las páginas Web dinámicas modifican la
página Web en respuesta a los eventos. Éstas se pueden
construir como páginas Web tridimensionales. Las técnicas
de Ajax solicitan y reciben una pequeña cantidad de datos
del servidor y utilizan estos datos para modificar la página
Web al instante.
Los formularios para llenar en Web se deben construir
con los siguientes siete lineamientos en mente, así como con
los descritos en el capítulo 11:
1. Proveer instrucciones claras.
2. Demostrar una secuencia de entrada lógica para los
formularios de llenado.
3. Usar variedad de cuadros de texto, botones, menús
desplegables, casillas de verificación y botones de opción.
4. Proveer un cuadro de texto desplazable si no está seguro
sobre cuánto espacio necesitarán los usuarios para
responder a una pregunta.
5. Preparar dos botones básicos en todo formulario de
llenado en Web: Enviar y Borrar formulario.
6. Si el formulario es extenso y los usuarios se deben
desplazar con mucha frecuencia, divídalo en varios
formularios más simples en páginas separadas.
7. Crear una pantalla de retroalimentación que resalte los
errores en un color apropiado y se niegue a enviar un
formulario a menos que se llenen los campos obligatorios
correctamente.
PALABRAS CLAVE Y FRASES
Ajax
botón aumentar/disminuir
botón de comando
botón de opción
campo oculto
capa
casilla de verificación
color en pantalla
control de formularios de negocios
control deslizante
cuadro de diálogo en pantalla
cuadro de lista
cuadro de lista desplegable
cuadro de mensaje
cuadro de texto
cursor
facilitar el movimiento en las páginas
flujo del formulario
formulario especializado
formulario para llenar en Internet/intranet
icono en pantalla
indicador
leyenda de línea
leyenda de tabla
leyenda de verificación horizontal
leyenda de verificación vertical
leyenda enmarcada
mapa de imagen
mostrar combinaciones de colores
páginas Web dinámicas
plano base
siete secciones de un formulario
máscaras (skins)
tabla de respuesta a eventos
tiempo de respuesta
tres secciones de una pantalla
valores del formulario
PREGUNTAS DE REPASO
1. ¿Cuáles son los objetivos de diseño para los formularios de entrada en papel, las pantallas de entrada o los formularios
para llenar en Web?
2. Mencione los cuatro lineamientos para el diseño de buenos formularios.
3. ¿Qué es el flujo apropiado de un formulario?
4. ¿Cuáles son las siete secciones de un buen formulario?
5. Mencione cuatro tipos de leyendas para usar en los formularios.
6. ¿Qué es un formulario especializado? ¿Cuáles son algunas desventajas de usar formularios especializados?
7. Mencione los cuatro lineamientos para el buen diseño de pantallas.
8. ¿Cuáles son las tres secciones útiles para simplificar una pantalla?
9. ¿Cuáles son las ventajas de usar ventanas en pantalla?
10. ¿Cuáles son las desventajas de usar ventanas en pantalla?
11. Mencione dos formas en que se puede mantener la consistencia en las pantallas.
12. Mencione tres formas para facilitar el movimiento entre las páginas de visualización.
13. Mencione cuatro elementos de diseño de interfaz gráfica. Describa a un lado de cada elemento cuándo sería apropiado
incorporarlo en un diseño de pantalla o en un formulario para llenar en Web.
14. ¿Cuándo se deben usar las casillas de verificación?
15. ¿Cuándo se deben usar los botones de opción?www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 395
16. ¿Cuáles son las dos formas distintas en que se utilizan los valores de un formulario?
17. ¿Para qué se utilizan los campos ocultos en un formulario Web?
18. Mencione cuatro tipos de eventos.
19. ¿Qué son las páginas Web dinámicas?
20. ¿Qué son las páginas Web tridimensionales?
21. ¿Cómo mejora Ajax una página Web que cambia en base a las acciones de los usuarios?
22. Mencione las cinco combinaciones más legibles de colores de primer plano y de fondo para usarlas en las pantallas.
23. Defina lo que significa el término máscaras cuando se utilizan en el diseño Web.
24. ¿Cuáles son las cuatro situaciones en las que el color puede ser útil para el diseño de pantallas y de formularios para
llenar en Web?
25. Mencione los siete lineamientos de diseño para un formulario de llenado basado en Web.
PROBLEMAS
1. He aquí las leyendas que se utilizan para un formulario de censo estatal en los EE.UU.:
Nombre
_____________________________________
Ocupación
_____________________________________
Dirección
_____________________________________
Código postal
_____________________________________
Número de personas que viven en el hogar
_____________________________________
Edad del jefe de familia
_____________________________________
a. Rediseñe las leyendas de manera que el buró de censo estatal pueda capturar la misma información que se solicita en
el formulario anterior sin confundir a quienes lo van a llenar.
b. Rediseñe el formulario de manera que exhiba un flujo apropiado. (Sugerencia: Cerciórese de proveer una sección de
acceso e identificación, de manera que la información se pueda almacenar en el sistema computarizado estatal.).
c. Rediseñe el formulario de manera que lo puedan llenar los ciudadanos que visitan el sitio Web del estado. ¿Qué
cambios fueron necesarios para cambiar de un formulario en papel a uno que se enviará en forma electrónica?
2. El Elkhorn College necesita llevar un mejor registro de los estudiantes y todos los que utilizan las computadoras
disponibles en la biblioteca Buck Memorial Library.
a. Diseñe y dibuje una representación de una pantalla de visualización que los estudiantes puedan usar para iniciar
sesión en las computadoras de la biblioteca. Etiquete las tres secciones de una pantalla que incluyó.
b. Diseñe un formulario en papel para dejarlo a un lado de cada computadora diariamente, con el fin de que los
usuarios de la comunidad (pero que no sean estudiantes) lo llenen de manera obligatoria. El formulario debe pedir el
nombre, la fecha y hora de la visita, el propósito general de uso de la computadora (por ejemplo, procesamiento de
palabras, navegar en la Web, examinar los documentos de bienes raíces en línea) y la hora en que cerraron sesión.
Etiquete las siete secciones de un formulario que incluyó.
3. Speedy Spuds es un restaurante de comida rápida que ofrece todo tipo de papas. El gerente tiene una regla de 30
segundos para atender a los clientes: los dependientes del mostrador dicen que podrían alcanzar esa regla si se
simplificara el formulario que deben llenar y entregar al personal de la cocina. La información del formulario lleno
se introduce en el sistema computarizado al final del día, cuando el capturista necesita introducir el tipo de papas que se
compró, los aderezos adicionales que se pidieron, la cantidad y el precio cobrado. Es difícil que los dependientes puedan
escanear y llenar con rapidez el formulario actual.
a. Diseñe y dibuje un formulario (usted elige el tamaño, pero sea considerado) que enliste las posibles variedades de
papas y aderezos de una manera que facilite a los dependientes del mostrador y al personal de cocina el proceso
de digitalizar, y que también se pueda utilizar como entrada para el sistema de inventario/reordenamiento en la
extranet que conecta a Speedy Spuds con los cultivadores de papas de Idaho. (Sugerencia: Recuerde observar todos
los lineamientos para el buen diseño de formularios.).
b. Diseñe y dibuje una representación de una pantalla de visualización que puedan usar los dependientes y oficinistas
para llenar la información capturada en el formulario.
c. Diseñe una pantalla de visualización basada en la pantalla que diseñó en el problema 3b. Esta vez debe funcionar
como una pantalla que muestre a un miembro del equipo de cocina qué debe preparar para cada pedido de Spuds.
Mencione tres cambios que haya hecho a la pantalla existente para adaptarla de manera que funcione como pantalla
de salida.www.xlibros.com

396 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
4. Sherry’s Meats, una empresa mayorista y minorista de carne regional, necesita recopilar información actualizada sobre
la cantidad de cada producto de carne que tiene en cada tienda. Después usará esa información para calendarizar las
entregas desde su almacén central. En la actualidad, los clientes que entran a la tienda llenan un formulario detallado en
el que especifican sus pedidos individuales. El formulario muestra más de 150 artículos; incluye carne y productos
derivados disponibles en distintas cantidades. Al final del día se tabulan entre 250 y 400 pedidos de los clientes y se
deducen del inventario de la tienda. Después, el trabajador de la oficina en cada tienda llama por teléfono para meter un
pedido para el siguiente día. Los empleados de las tiendas tienen problemas para tabular las ventas debido a los errores
que cometen los clientes al llenar sus formularios.
a. No es posible hacer que el trabajador de oficina solitario en cada tienda llene los numerosos formularios de
pedido de los clientes. Cambie el formulario (de 3 1 2 6, ya sea horizontal o vertical) y dibújelo de manera que
sea más fácil para los clientes llenarlo en forma correcta y que los trabajadores puedan tabularlo con mayor
facilidad.
b. Diseñe y dibuje un formulario especializado del mismo tamaño que cumpla con las necesidades de los clientes de
Sherry’s, los trabajadores de oficina y los trabajadores del almacén.
c. Diseñe y dibuje dos formularios distintos del mismo tamaño para cumplir con los propósitos del problema 4b, ya
que Sherry ́s vende productos avícolas y de res. (Sugerencia: Piense en las formas para hacer que sea fácil distinguir
los formularios visualmente.).
d. Diseñe un formulario para llenar en una pantalla. Cuando un cliente envía un pedido, cualquier persona que atienda
a los clientes en el mostrador lo introduce en el sistema de inventario de Sherry’s. Esta información se capturará y
enviará a la computadora del almacén central para ayudar a controlar el inventario.
e. Describa en un párrafo las desventajas de que muchas personas distintas introduzcan datos desde diferentes
ubicaciones. Mencione en un párrafo los pasos que puede llevar a cabo como diseñador para diseñar el formulario a
llenar de manera que se asegure la precisión en la entrada de datos.
f. Diseñe una página Web utilizada por un cliente para introducir un pedido directamente a Sherry ́s.
g. Diseñe una página Web para obtener la información de la tarjeta de crédito para un pedido en Web. Particione los
datos en dos páginas Web para obtener seguridad adicional.
h. Diseñe una página Web dinámica tridimensional que permita a Sherry’s personalizar ciertos productos, como el
solicitar ingredientes específicos en un pastel de carne o en una ensalada. Cuando el cliente seleccione un producto
de una lista desplegable deberán aparecer los ingredientes y debe haber una forma de poder seleccionar los que el
cliente desee incluir en el producto.
5. La tienda de ropa de moda R. George’s, que también cuenta con un negocio de catálogo, desea llevar el registro de los
clientes que entran en la tienda para poder expandir su lista de correo.
a. Diseñe y dibuje un formulario simple que se pueda imprimir en tarjetas de 3 5 para repartirlo a los clientes y
que lo llenen. (Sugerencia: El formulario debe tener una estética atractiva para animar a que la clientela exclusiva de
R. George’s lo llene.).
b. Diseñe y dibuje una representación de una pantalla de visualización que capture la información de los clientes en la
tienda a través de las tarjetas del problema 5a.
c. Diseñe y dibuje un segundo cuadro de diálogo de controles con pestañas en la pantalla que compare a los clientes en
la tienda con los clientes de catálogo.
d. El propietario desea que usted le ayude a mejorar su negocio de ventas por catálogo mediante el establecimiento
de un sitio de comercio electrónico. Diseñe un formulario basado en Web para capturar la información de todos
los que visitan el sitio Web. Explique en un párrafo las diferencias que tendrá en comparación con el formulario
impreso.
6. Hace poco, una prometedora agencia de corredores de bolsa con descuento expresó su interés en desarrollar su
propio software de administración de carteras basado en Web, que los clientes puedan usar desde su hogar en sus
PC para realizar transacciones comerciales, obtener cotizaciones de acciones en tiempo real y llevar a cabo otras
acciones.
a. Diseñe dos pantallas de entrada que faciliten al cliente la introducción de datos. La primera pantalla debe permitir a
los usuarios introducir los símbolos para las acciones que desean rastrear a diario. La segunda pantalla debe permitir
al cliente usar un sistema basado en iconos para diseñar un informe personalizado que muestre las tendencias en los
precios de las acciones en una variedad de gráficos o de texto.
b. Sugiera otras dos pantallas de entrada que se deban incluir en este nuevo software de administración de carteras.
7. My Belle Cosmetics es una gran empresa que tiene ventas mucho mayores a las de cualquier otra empresa regional
de cosméticos. Como organización es muy sensible al color, ya que introduce nuevas líneas de colores en sus
productos cada otoño y primavera. Hace poco, la empresa empezó a utilizar la tecnología para mostrar en forma
electrónica a los clientes en las tiendas cuál sería su apariencia con distintas sombras de cosméticos sin tener que
aplicárselos.
a. Diseñe y dibuje una representación de una pantalla que puedan usar las vendedoras en el mostrador para probar
varias sombras de lápiz labial y maquillaje en un cliente individual con mucha rapidez y alto grado de precisión. La
entrada de los clientes debe ser el color de su cabello, el color de su ropa favorita y la iluminación común en su
entorno (fluorescente, incandescente, exteriores, etcétera).www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 397
b. Diseñe y dibuje una representación de una pantalla que sea equivalente a la del problema 7a pero que demuestre
vívidamente a los encargados de tomar decisiones en My Belle cómo es que el color mejora la capacidad de
comprender la pantalla.
c. Uno de los afiliados que tiene My Belle en la Web cuenta con una extensa cadena de tiendas departamentales.
Describa en un párrafo cómo se podría alterar la pantalla del problema 7a de manera que un individuo pueda usarla
y My Belle pueda colocarla en el sitio de comercio electrónico de la tienda departamental para atraer clientes.
8. La empresa Home Finders Realty Corporation se especializa en localizar casas para compradores potenciales. La
información sobre las casas se almacena en una base de datos y se muestra en una pantalla de consulta. Diseñe una
pantalla basada en Web con GUI y campos para introducir los siguientes datos, empleados para seleccionar y mostrar las
casas que coincidan con los criterios. Tenga en cuenta las características disponibles para una pantalla de GUI. Los
elementos de diseño (que no se encuentran en ninguna secuencia específica) son:
a. Tamaño mínimo (en pies cuadrados).
b. Tamaño máximo (en pies cuadrados, opcional).
c. Número mínimo de recámaras.
d. Número mínimo de baños.
e. Tamaño de la cochera (número de autos, opcional).
f. Distrito escolar (hay un número limitado de distritos escolares disponibles en cada área).
g. Alberca (sí/no, opcional).
h. Ambiente (ciudad, suburbios o rural).
i. Chimenea (sí/no, opcional).
j. Uso eficiente de energía (sí/no).
Describa además los hipervínculos necesarios para lograr este tipo de interacción.
9. Diseñe una página de entrada Web para la pantalla de visualización de Home Finders Realty Corporation que creó en el
problema 8.
10. La cadena hotelera TowerWood de cinco años de antigüedad necesita ayuda para diseñar su sitio Web. La empresa
mantiene propiedades en todas las grandes comunidades turísticas de los EE.UU. como Orlando, Florida (cerca de
Disney World); Maui, Hawaii; Anaheim, California (cerca de Disneyland); Las Vegas, Nevada; y Nueva Orleans,
Luisiana. Sus propiedades incluyen una variedad de habitaciones en todas estas ubicaciones.
a. Describa en un párrafo cómo puede la empresa usar máscaras en su sitio Web para atraer distintos tipos de clientela,
incluyendo familias con niños pequeños, parejas jóvenes en su luna de miel, parejas retiradas que desean viajar con
un presupuesto establecido y los viajeros de empresas que necesitan servicios de negocios.
b. Diseñe y dibuje una serie de máscaras que atraigan a los distintos tipos de clientela para el hotel que se enlistan en el
problema 10a. (Sugerencia: Use un paquete de gráficos o un programa de dibujo para ayudar a diseñar las
máscaras.).
c. Agregue un grupo de usuarios potenciales del sitio Web para la cadena hotelera TowerWood que no fueron
mencionados en el problema 10a; diseñe y dibuje máscaras adicionales para ellos. Después cree una tabla que
relacione cada grupo de clientes con una máscara específica que haya diseñado.
11. Sludge’s Auto es un centro de reciclaje de auto partes, incluyendo autos clásicos y antiguos. Rhode Wheeler, el
propietario, desea elaborar un sitio Web para que los clientes exploren el catálogo de piezas. Diseñe una página Web con
Ajax que se utilice para buscar las piezas. El cliente necesita conocer la marca, modelo y año de un auto, así como la
pieza. Si la pieza está en existencia deberán aparecer la descripción, condición de la pieza, precio y costo de envío, con
la cantidad disponible para cada pieza, junto con una imagen de la misma. Provea un botón para cada pieza en el que se
pueda hacer clic para comprarla.
12. Diseñe la página Web Agregar cliente para Sludge’s Auto. Incluya un perfil que permita a Sludge’s enviar al cliente un
correo electrónico si cierta pieza está disponible.
13. Diseñe la página Comprar en Web para Sludge’s Auto. Suponga que el cliente ya se agregó y que ha iniciado sesión.
Muestre cierta información sobre el cliente. Divida la información de la tarjeta de crédito (tipo de tarjeta de crédito,
número de tarjeta de crédito, fecha de expiración y el código de seguridad en la parte trasera de la tarjeta) entre dos
páginas Web.
14. Diseñe una página Web que utilice Ajax para registrar un producto electrónico, ya sea de hardware o de software. El
formulario deberá tener el nombre y la dirección del comprador, el número telefónico, la dirección de correo electrónico
y una lista desplegable de categorías de productos. Al modificar la categoría, hay que enviar el valor de ésta al servidor,
el cual devolverá un documento de XML que contiene los productos para la categoría, que se utilizarán para crear una
lista desplegable de productos. Cuando el cliente seleccione un producto, se enviará el valor del producto al servidor, el
cual devolverá un documento XML que se utilizará para crear un modelo o versión del producto.
PROYECTOS EN GRUPO
1. Maverick Transport está considerando actualizar sus pantallas de visualización de la entrada. Realice una sesión de
lluvia de ideas con su equipo en relación con lo que debe aparecer en las pantallas de entrada de los operadores
de computadora que introducen los datos de las cargas de las entregas a medida que se aprueban las cargas. Los campos
incluirán la fecha de entrega, el contenido, el peso, los requerimientos especiales (por ejemplo, si el contenido es
perecedero), y así en lo sucesivo.www.xlibros.com

398 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
2. Cada miembro del equipo debe diseñar una pantalla de entrada apropiada mediante una herramienta CASE, una
herramienta de dibujo como Microsoft Visio o lápiz y papel. Comparta sus resultados con los miembros de su equipo.
3. Haga una lista de otras pantallas de entrada que debería desarrollar Maverick Transport. Recuerde incluir pantallas para
el despachador así como las pantallas a las que accederán los clientes y conductores. Indique cuáles deberían ser
pantallas de PC o pantallas en dispositivos portátiles inalámbricos.
4. Diseñe una pantalla basada en Web que permita a los clientes de Maverick Transport rastrear el progreso de un envío.
Realice una sesión de lluvia de ideas con los miembros del equipo para obtener una lista de elementos, o haga una
entrevista en una empresa de transporte local para averiguar sus requerimientos. Haga una lista de los hipervínculos que
serán esenciales. ¿Cómo controlaría el acceso de manera que los clientes sólo puedan rastrear sus propios envíos?
BIBLIOGRAFÍA SELECCIONADA
Direct Ferries. “Web Site Uses Ajax in Their Application”. www.directferries.co.uk/poirishsea.htm. Último acceso en julio 31,
2009.
Garrett, J. J. “Ajax: A New Approach to Web Applications”. Febrero 18, 2005, www.adaptivepath.com. Último acceso: 31 de
julio de 2009.
Google Suggest. “Web Site That Uses Ajax”. www.google.com/webhp?complete=1&hl=en. Último acceso: 31 de julio de
2009.
Ives, B. “Graphical User Interfaces for Business Information Systems”. MIS Quarterly (edición especial), diciembre 1982, pp.
15-48.
Kyng, M. y L. Mathiassen. Computers and Design in Context. Cambridge, MA: MIT Press, 1997.
Nielsen, J., R, Molich, C. Snyder y S. Farrell. E-Commerce User Experience. Fremont, CA; Nielsen Norman Group, 2001.
Reisner, P. “Human Factors Studies of Data Base Query Languages: A Survey and Assessment”. Computing Surveys, Vol. 4,
Núm. 1, 1981.
Schmidt, A. y K. E. Kendall. “Using Ajax to Clean Up a Web Site: A New Programming Technique for Web Site Development”.
Decision Line, octubre de 2006, pp. 11-13.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 399
E P I S O D I O 1 2
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Formando pantallas y visualizando formularios
Reuniendo información del diseño de la salida y revisando su progreso, Chip y Anna proceden a la siguiente etapa: el diseño de
la entrada. “Las páginas Web se deben diseñar de manera que se pueda capturar la información de entrada con facilidad y pre-
cisión”, comenta Anna.
Chip empieza a trabajar en la modificación de la pantalla que se utiliza para introducir los datos del formulario. En la figura
E12.1 se muestra la pantalla de entrada AGREGAR NUEVA COMPUTADORA (ADD NEW COMPUTER). Una de las con-
sideraciones de la pantalla de entrada es la facilidad al introducir los datos; otra es la precisión. Otra consideración más es la
disponibilidad de la ayuda. Los nuevos empleados no estarían familiarizados con la operación del sistema o con lo que se re-
quiere para una entrada de un campo específico. Para lograr estos objetivos, Chip incluye listas desplegables para UNIDAD
ÓPTICA (OPTICAL DRIVE), TIPO DE COMPUTADORA (COMPUTER TYPE) y SISTEMA OPERATIVO (OPERATING
SYSTEM). “Me gusta la forma en que trabajan estas listas desplegables”, le comenta a Anna. “Los usuarios pueden seleccionar
con facilidad los códigos que se deberían almacenar en la base de datos”.
“¿Por qué hacer que los usuarios seleccionen códigos?”, responde Anna. “Debe haber una forma de que puedan seleccio-
nar significados descriptivos del código, como el nombre del sistema operativo, y de hacer que la computadora almacene los
códigos”.
“¡Es una excelente idea!”, exclama Chip. Poco tiempo después se implementan las modificaciones.
Anna revisa la pantalla de visualización y comenta: “¡Se ve excelente! Me gusta el agrupamiento de las casillas de verifi-
cación y la información descriptiva contenida en las listas desplegables”.
“Mira ésta en acción”, dice Chip. “Agregué un botón para que los usuarios lo opriman cuando hayan encontrado todos los
datos y hayan realizado todas las selecciones. También pueden imprimir el formulario lleno”.
“¿Qué hay sobre la ayuda?”, pregunta Anna.
“También pensé en eso”, le responde Chip. “Al mover el cursor de un campo a otro, la línea de estado en la parte inferior
de la pantalla muestra una línea de ayuda apropiada para ese campo. También puedo agregar ayuda en forma de cuadros de
información sobre las herramientas, un pequeño cuadro de opciones de ayuda que aparece cuando el cursor permanece sobre
un área de entrada durante un periodo breve de tiempo”. Observe que las listas desplegables tienen nombres significativos en
las áreas de datos. La ayuda se muestra en la línea de estado en la parte inferior de la pantalla.
Dot revisa la pantalla completa e introduce algunos datos de prueba. “¡Estoy realmente impresionado!”, exclama. “Es
mucho mejor de lo que esperaba. ¿Cuándo podemos esperar el resto del sistema?”, sonríe Chip con aprecio y recalca el excelente
progreso que se está llevando a cabo. “¡Espero que el resto del sistema sea tan claro de usar y fácil de operar!”, dice Dot en tono
agradecido.
Mientras tanto Anna se reúne con Hy Perteks, quien busca ayuda con desesperación. “¡Estoy inundado de peticiones de
ayuda sobre los paquetes de software! ¿Hay alguna forma de diseñar una porción del sistema para mantener la información
FIGURA E12.1
Listas desplegables en la pantalla
AGREGAR NUEVA
COMPUTADORA
(ADD NEW COMPUTER)
en Microsoft Access.www.xlibros.com

400 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
sobre los expertos de software disponibles?”, pregunta Hy. “Tengo los nombres escritos en pedazos de papel y vivo perdiéndo-
los. A menudo averiguo quiénes son estos expertos sólo después de que alguien los encuentra primero”.
Anna le hace algunas preguntas sobre la información requerida y cómo le gustaría a Hy mantener y mostrar los registros.
Hy responde: “Hay tantos expertos disponibles, pero la única forma que tengo de localizar la información de la persona es si
utilizo su nombre como índice. Y debo confesar que soy pésimo al recordar la escritura correcta del primer nombre, mucho
menos el apellido”. Anna le asegura que pronto habrá un sistema fácil de usar.
De regreso en su escritorio, Anna piensa en el problema. “La pantalla AGREGAR (ADD) sería muy fácil de crear, pero
¿qué hay de la pantalla CAMBIAR (CHANGE)?”. Se pregunta “¿Cómo puedo?”, y después piensa, “¡Muy bien!” mientras
chasquea sus dedos. El diseño se vuelve más claro. Debe haber una pantalla con dos regiones distintas en ella. La primera debe
contener el primer nombre y el apellido del experto de software. En la pantalla se incluye un botón Buscar (Find) así como
botones para desplazarse hacia delante y hacia atrás por los registros. Si los usuarios cometen un error al introducir los datos,
hay un botón Deshacer (Undo) y también hay un botón para guardar los cambios. La pantalla completa se muestra en la figura
E12.2.
“Excelente pantalla”, sonríe Chip. “Quiero estar aquí cuando se la enseñes a Hy”.
El problema de eliminar los registros de los cursos de software que ya no se utiliza requiere un enfoque distinto. Anna
razona que sería sencillo si utilizara la característica Buscar (Find) para localizar un registro y después utilizara un botón Find
Next (Encontrar siguiente) para localizar el siguiente registro que coincida con los criterios. También debe haber botones que
le permitan avanzar al siguiente registro o al anterior (vea ELIMINAR CURSO DE SOFTWARE [DELETE SOFTWARE
COURSE]).
Una vez localizado el registro, el programa ELIMINAR CURSO DE SOFTWARE debe mostrar la información pertinente.
Todos los códigos en el archivo, como NIVEL DE CURSO (COURSE LEVEL) y SISTEMA OPERATIVO (OPERATING
SYSTEM) se deben sustituir con el significado completo del código. Los datos no se podrán modificar en este momento. El
operador tendrá la oportunidad de revisar el registro y después elegir si lo desea o no eliminar. Al hacer clic en el botón para
eliminar, aparecerá un cuadro de diálogo preguntando a los usuarios si realmente desean eliminar el registro. Pueden optar por
cancelar la eliminación en ese momento.
Hy está encantado con los prototipos de las pantallas de visualización. Mientras prueba cada una de ellas, comenta: “No
saben lo fácil que será para mí responder a las solicitudes de ayuda. ¡Son fabulosas!”. Se detiene por un buen rato y después
pregunta: “Recibo muchas solicitudes sobre ofrecer cursos de capacitación programados en forma periódica. ¿Creen que po-
dríamos trabajar en un sistema para registrarse en los cursos?
Anna busca sus labios por un momento y comenta: “¿Alguna vez escuchó de un proyecto en el que siempre se agregan
pequeñas cosas y nunca termina? Sin embargo, la universidad tiene una iniciativa Web. Podemos diseñar una página Web inte-
ractiva para registrar los cursos”.
“¡Magnífico!”, responde Hy. “Es más de lo que jamás hubiera esperado”.
Anna empieza a diseñar la página Web, incluyendo nombre y apellido de los usuarios junto con sus direcciones de correo
electrónico y teléfonos de oficina. Se utilizan áreas adicionales para introducir el campus en donde se encuentran, el software
que utilizan y su nivel de clase. Chip revisa el formulario y comenta: “¿Qué tal si usamos Ajax para que introduzcan su dirección
de correo electrónico del campus y hagan clic en un botón Buscar empleado? El servidor buscaría los empleados y después
llenaría la página Web con el primer nombre y el apellido de cada empleado, junto con su teléfono de oficina. Podrían sobres-
cribir el teléfono de oficina con un celular si salieran de viaje. En vez de que tengan que introducir la información del campus
y del software, ¿por qué no hacemos que seleccionen opciones de una lista desplegable? ¿Y qué tal si les permitimos seleccio-
nar los horarios convenientes para la capacitación?”.
FIGURA E12.2
La pantalla CAMBIAR
EXPERTO DE SOFTWARE
(CHANGE SOFTWARE
EXPERT) de Microsoft Access.www.xlibros.com

CAPÍTULO 12 • DISEÑO DE UNA ENTRADA EFECTIVA 401
“Buena idea”, responde Anna. “Y creo que los niveles de capacitación deben estar también en una lista desplegable”. La
página Web de intranet completa se muestra en la figura E12.3. Observe que hay botones para enviar la consulta o restablecerla
y una lista desplegable que contiene el campus como valor predeterminado. Otras listas desplegables contienen instrucciones
sobre lo que se debe seleccionar. Hay casillas de verificación a la izquierda para seleccionar los cursos en los que se van a re-
gistrar. En la parte inferior se incluye un vínculo para enviar las preguntas por correo electrónico al instructor de capacitación.
Hy está encantado. “Este formulario es mejor de lo que jamás imaginé. Creo que realmente estamos proporcionando un
registro de capacitación efectivo, y sé que mi teléfono ya no sonará tanto. ¡Tengo otra gran idea!”.
Para realizar los siguientes ejercicios, puede diseñar el informe o pantalla mediante formularios de diseño, o crearlos a
través de cualquier procesador de palabras con el que esté familiarizado. Los campos y demás información relacionada con los
informes se incluyen en una página Web del repositorio o en las entradas del repositorio de flujo de datos de Visible Analyst.
En cada ejercicio se enlistan los nombres para el flujo de datos.
Se crearon los informes y pantallas correspondientes (conocidos como formularios en Microsoft Access). Toda la informa-
ción está presente en la base de datos de Microsoft Access; usted sólo tiene que modificar los informes y pantallas existentes
para producir las versiones finales. Para hacer las modificaciones, haga clic en el informe o pantalla deseada y después haga clic
en el botón Design (Diseño). Puede realizar las siguientes modificaciones. El Page Header (Encabezado de página) contiene
los encabezados de las columnas. El área Detail (Detalle) contiene los campos a imprimir para el informe.
Haga clic en un campo para seleccionarlo. Haga clic en varios campos mientras oprime la tecla Mayús para seleccionarlos.
Arrastre un campo (o campos) seleccionado para moverlo.
Haga clic en una de las cajas pequeñas que rodean el campo para cambiar su tamaño.
Seleccione varios campos, haga clic en Format (Formato) y después en una de las siguientes opciones:
Align (Alinear), para alinear todos los campos con el campo superior o el izquierdo, por ejemplo.
Size (Ajustar tamaño), para hacer todos los campos iguales al campo más ancho o el más alto, por ejemplo.
Horizontal Spacing (Espacio horizontal), para hacer el espacio horizontal igual, aumentarlo o reducirlo.
Vertical Spacing (Espacio vertical), para hacer el espacio vertical igual, aumentarlo o reducirlo.
EJERCICIOS
E-1. Cher Ware ha comentado varias veces que un buen formulario facilitaría de manera considerable la tarea de agregar nuevo
software. También ofrecería documentación permanente en papel para las adiciones de software.
Diseñe un formulario para agregar software al ARCHIVO MAESTRO DE SOFTWARE (SOFTWARE MASTER).
Abra el Diagrama de flujo de datos 0 en Visio o Visible Analyst. Vea la entrada del repositorio FORMULARIO DE
SOFTWARE RECIBIDO (SOFTWARE RECEIVED FORM) para el flujo de datos. Haga clic en el vínculo para el
NUEVO REGISTRO DE SOFTWARE (NEW SOFTWARE RECORD) en la Composición (Composition) para ver la
estructura de datos que contiene los elementos requeridos en el formulario. Haga clic en el vínculo (o en Saltar [Jump]
en Visible Analyst) a cada elemento para determinar la longitud del campo en pantalla.
E-2. Diseñe la pantalla AGREGAR REGISTRO DE SOFTWARE (ADD SOFTWARE RECORD), ya sea en papel o modificando
la pantalla de Microsoft Access. Use los campos que creó en el ejercicio E-1. El nombre de la estructura de datos de la página
Web del repositorio o de Visible Analyst es NUEVO REGISTRO DE SOFTWARE (NEW SOFTWARE RECORD).
FIGURA E12.3
Un formulario Web de intranet
para el Registro de capacitación
(Training Registration) en el sitio
Web de la CPU.www.xlibros.com

402 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
E-3. Hy Perteks desea un formulario para llenarlo a medida que aprende sobre los nuevos expertos de software. Use la estruc-
tura de datos del repositorio llamada AGREGAR EXPERTO DE SOFTWARE (ADD SOFTWARE EXPERT) para de-
terminar los campos requeridos para el formulario.
E-4. Cree la pantalla AGREGAR EXPERTO DE SOFTWARE en papel, mediante el uso de un procesador de palabras o
modifique el formulario de Microsoft Access. Pruebe la pantalla AGREGAR EXPERTO DE SOFTWARE; use la lista
desplegable y observe la barra de estado en la parte inferior de la pantalla.
E-5. Diseñe o modifique el formulario de Microsoft Access para la pantalla ELIMINAR EXPERTO DE SOFTWARE
(DELETE SOFTWARE EXPERT). ¿Qué campos son listas desplegables? Use la estructura de datos del reposito-
rio llamada ELIMINAR EXPERTO DE SOFTWARE.
E-6. Diseñe o modifique el formulario de Microsoft Access para la pantalla ELIMINAR REGISTRO DE COMPUTA-
DORA (DELETE COMPUTER RECORD). La estructura de datos del repositorio se llama ELIMINAR REGIS-
TRO DE COMPUTADORA.
E-7. Cher Ware y Anna pasaron una buena parte de una mañana trabajando en los detalles sobre la porción de software del
sistema. Invadida por el problema de proveer actualizaciones de software consistentes para todas las máquinas, a Cher le
gustaría un método fácil para la actualización. Tal vez se retengan unas cuantas versiones antiguas de software para ne-
cesidades especiales.
Parte de la solución es producir un informe, ordenado por ubicación, de todas las máquinas que contengan el software que
se va a actualizar. A medida que se instala el nuevo software se coloca una marca en el informe después de cada máquina.
Diseñe la pantalla ACTUALIZAR SOFTWARE (UPGRADE SOFTWARE). Agregue un botón Buscar (Find) para
localizar el título y proveer un campo que se pueda utilizar para introducir el nuevo NÚMERO DE VERSIÓN (VERSION
NUMBER). El programa de actualización mostrará una línea para cada máquina que contenga la versión anterior del
software instalado. Estas líneas se ordenan por UBICACIÓN DE CAMPUS (CAMPUS LOCATION) y UBICACIÓN
DE SALA (ROOM LOCATION).
Las columnas son UBICACIÓN DE CAMPUS (CAMPUS LOCATION). UBICACIÓN DE SALA (ROOM LOCA-
TION), NÚMERO DE INVENTARIO (INVENTORY NUMBER), NOMBRE DE MARCA (BRAND NAME), MODELO
(MODEL), ACTUALIZACIÓN (UPGRADE) y RETENER VERSIÓN ANTERIOR (RETAIN OLD VERSION). La co-
lumna ACTUALIZACIÓN contiene una casilla de verificación que se debe marcar si el software se va a actualizar. RE-
TENER VERSIÓN ANTERIOR también es una casilla de verificación, la cual está desmarcada de manera predeterminada.
Los usuarios marcan esa casilla para una máquina específica que deba retener las versiones anterior y nueva del software.
Busque en la estructura de datos del repositorio llamada ACTUALIZAR SOFTWARE (SOFTWARE UPGRADE)
los elementos contenidos en la pantalla.
E-8. Explique por qué la pantalla ACTUALIZAR SOFTWARE (SOFTWARE UPGRADE) debe mostrar las máquinas en vez
de hacer que Cher introduzca los ID de las máquinas. Describa en un párrafo por qué la pantalla muestra los registros en
una secuencia CAMPUS/SALA.
E-9. Diseñe la pantalla CAMBIAR SOFTWARE (CHANGE SOFTWARE). Esta pantalla permite a Cher Ware modificar
datos que se hayan introducido en forma incorrecta, además de información que cambia en forma rutinaria, como EX-
PERTO DE SOFTWARE (SOFTWARE EXPERT) y NÚMERO DE COPIAS (NUMBER OF COPIES). El NÚMERO
DE INVENTARIO DE SOFTWARE (SOFTWARE INVENTORY NUMBER) es la clave primaria y no se debe cambiar.
Los demás campos del ARCHIVO MAESTRO DE SOFTWARE (SOFTWARE MASTER) que se deben incluir en la
pantalla se encuentran en la estructura de datos del repositorio llamada SOFTWARE CHANGES (CAMBIOS DE SOFT-
WARE). Use estos campos para diseñar la pantalla. Se creó en Microsoft Access una pantalla limitada llamada CAM-
BIAR REGISTRO DE SOFTWARE (CHANGE SOFTWARE RECORD); use la Lista de campos (Field List) de
Microsoft Access para agregarle campos. Incluya los siguientes botones: Buscar (Find), Buscar siguiente (Find Next),
Registro anterior (Previous Record), Siguiente registro (Next Record), Guardar registro (Save Record) y Cancelar
cambios (Cancel changes).
E-10. Hy Pertks está preocupado de que los cursos anteriores para las versiones obsoletas de software estén atiborrando los
discos. Cree e imprima la pantalla ELIMINAR CURSO DE SOFTWARE (DELETE SOFTWARE COURSE).
Los campos de entrada son TÍTULO DE SOFTWARE (SOFTWARE TITLE), SISTEMA OPERATIVO (OPERA-
TING SYSTEM) y NÚMERO DE VERSIÓN (VERSION NUMBER). El programa muestra una lista para cada curso
que se enseña para la versión de software especificada. La primera columna contiene un campo de entrada con una D (de
eliminar, delete) que se presenta como valor predeterminado. Al colocar un espacio en el campo el registro no se elimi-
nará. Las demás columnas para cada línea son TÍTULO DEL CURSO (COURSE TITLE), NIVEL (LEVEL) y DU-
RACIÓN DE LA CLASE (CLASS LENGTH). Agregue un mensaje significativo para el operador.
E-11. Diseñe la pantalla ACTUALIZAR INFORMACIÓN DE MANTENIMIENTO (UPDATE MAINTENANCE INFORMA-
TION). Esta pantalla contiene los campos de entrada que permiten a Mike Crowe cambiar la información de mantenimiento
a medida que se reparan computadoras o al realizar el mantenimiento de rutina en ellas. La estructura de datos del reposi-
torio es ACTUALIZAR INFORMACIÓN DE MANTENIMIENTO (UPDATE MAINTENANCE INFORMATION).
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar archivos de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.www.xlibros.com

403
C A P Í T U L O 1 3
Diseño de bases de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender los conceptos de bases de datos.
2. Usar la normalización para almacenar los datos con eficiencia en una base de datos.
3. Usar bases de datos para presentar la información.
4. Comprender el concepto de los almacenes de datos corporativos.
5. Comprender la utilidad de publicar las bases de datos en la Web.
Algunos consideran que el almacenamiento de datos es el corazón de un
sistema de información. En primer lugar, los datos tienen que estar disponibles
cuando el usuario desee utilizarlos; en segundo, deben ser precisos y consis-
tentes (es decir, deben poseer integridad). Además de estos requerimientos,
los objetivos del diseño de bases de datos incluyen asegurar la eficiencia en
el almacenamiento, la actualización y la recuperación de los datos. Por último, es necesario que la
recuperación de información tenga un propósito. La información que se obtiene de los datos al-
macenados debe estar en una forma que sea útil para la administración, la planeación, el control
o la toma de decisiones.
Hay dos metodologías para el almacenamiento de datos en un sistema basado en computa-
dora. La primera es almacenar los datos en archivos individuales, cada uno de los cuales es único
para cierta aplicación específica. La segunda implica la creación de una base de datos, es decir, un
almacén de datos formalmente definido y controlado centralmente, creado para emplearse en
distintas aplicaciones.
A menudo los archivos individuales se diseñan sólo para satisfacer una necesidad inmediata,
por lo que es importante que las consultas al sistema se realicen con base en una combinación de
algunos de los atributos, que pueden estar contenidos en archivos separados o ni siquiera existan.
Las bases de datos son planificadas, por lo que los datos se organizan de manera que se puedan
almacenar y recuperar con eficiencia. Los almacenes de datos corporativos son bases de datos
muy grandes que alojan datos sintetizados relacionados con un tema específico, para poder res-
ponder a las consultas de una manera muy eficiente.
BASES DE DATOS
Las bases de datos no son sólo una colección de archivos. Una base de datos es una fuente cen-
tral de datos con el fin de que varios usuarios la compartan para su uso en varias aplicaciones. El
corazón de una base de datos es el sistema de administración de bases de datos (DBMS), el cual
permite crear, modificar y actualizar la base de datos, la recuperación de los datos y la generación
de informes y pantallas. A la persona que asegura que la base de datos cumpla con sus objetivos se
le conoce como administrador de bases de datos.
Los objetivos de efectividad de la base de datos incluyen lo siguiente:
1. Asegurar que los datos se puedan compartir entre los usuarios y en varias aplicaciones.
2. Mantener datos precisos y consistentes.
3. Asegurar que todos los datos requeridos para las aplicaciones actuales y futuras estén siempre
disponibles.www.xlibros.com

404 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
4. Permitir que la base de datos evolucione a medida que aumenten las necesidades de los usuarios.
5. Permitir que los usuarios construyan su propia vista personal de los datos sin preocuparse por la forma en
que éstos se almacenan físicamente.
La anterior lista de objetivos constituye un recordatorio de las ventajas y desventajas de la metodología de las
bases de datos. En primer lugar, compartir los datos significa que éstos se deben guardar sólo una vez, lo que a
su vez ayuda a asegurar su integridad, ya que las modificaciones a éstos se realizan con más facilidad y confiabi-
lidad si los datos aparecen sólo una vez y no en muchos archivos distintos.
Cuando un usuario necesita ciertos datos específicos, una base de datos bien diseñada se anticipa a la
necesidad de dichos datos (o tal vez ya se hayan utilizado en otra aplicación). En consecuencia, los datos
tienen una mayor probabilidad de estar disponibles en una base de datos que en un sistema de archivos con-
vencional. Una base de datos bien diseñada también puede ser más flexible que varios archivos separados;
es decir, una base de datos puede evolucionar a medida que cambian las necesidades de los usuarios y las
aplicaciones.
Por último, la metodología de las bases de datos tiene la ventaja de permitir que los usuarios tengan su pro-
pia vista de los datos. Los usuarios no necesitan preocuparse de la estructura de la base de datos ni con su alma-
cenamiento físico.
Muchos usuarios extraen partes de la base de datos central de las mainframes y las descargan en PC o dis-
positivos portátiles. Después, estas bases de datos reducidas se utilizan para generar informes o responder a las
consultas específicas para el usuario final.
Las bases de datos relacionales para las PC han mejorado considerablemente durante los últimos años.
Uno de los principales cambios tecnológicos ha sido el diseño de software de base de datos que aprovecha
la GUI. Con la llegada de programas como Microsoft Access, los usuarios pueden arrastrar y soltar campos
entre dos o más tablas. El desarrollo de bases de datos relacionales con estas herramientas se ha facilitado
mucho.
CONCEPTOS DE DATOS
Es importante comprender cómo se representan los datos antes de considerar el uso de archivos o de la metodo-
logía de las bases de datos. En esta sección veremos algunas definiciones críticas, incluyendo la abstracción de
los datos del mundo real hasta el almacenamiento de los datos en tablas, y las relaciones de bases de datos.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 3 . 1
Enganche su carrito de limpieza a una estrella
La empresa Marc Schneider Janitorial Supply Company ha soli-
citado su ayuda para limpiar su almacén de datos. Tan pronto como
usted empieza a cuestionar a Marc Schneider con preguntas detalla-
das sobre su base de datos, el rostro de su interlocutor se ruboriza.
“En realidad no tenemos una base de datos de la manera en que la
describe”, dice con un poco de vergüenza. “Siempre he querido
limpiar nuestros registros, pero no pude encontrar una persona ca-
paz de hacerse cargo de esa tarea”.
Después de hablar con el Sr. Schneider, usted camina por el
pasillo hacia la oficina del tamaño de un clóset que pertenece a Stan
Lessink, el programador en jefe. Stan lo pone al tanto del desarrollo
histórico del actual sistema de información. “La historia de la em-
presa Marc Schneider Janitorial Supply Company es el típico relato
de mendigo a millonario”, comenta Stan. “El primer trabajo del Sr.
Schneider fue como conserje en un boliche. Ahorró el suficiente di-
nero para comprar algunos productos y empezó a venderlos a otros
boliches. Pronto decidió expandir el negocio de provisiones de lim-
pieza. Descubrió que, a medida que crecía su negocio, tenía más lí-
neas de productos y tipos de clientes. Los vendedores en la empresa
están asignados a las distintas líneas de productos principales (tiendas
y oficinas, por ejemplo); algunos están en ventas dentro de la empresa y
otros se especializan en equipo pesado, como las pulidoras y encera-
doras de pisos. Los registros se mantenían en archivos separados”.
Usted recuerda que el Sr. Schneider dijo: “El problema es que
no tenemos manera de comparar las ganancias de cada división.
Nos gustaría establecer programas de incentivos para los vendedo-
res y proveer un mejor balance al momento de asignar vendedores
a cada línea de productos”.
Sin embargo, al estar hablando con Stan, él agrega: “Cada di-
visión tiene su propio sistema de incentivos. Las comisiones varían.
No veo cómo podríamos tener un sistema común. Además, puedo
obtener nuestros informes con rapidez debido a que nuestros archi-
vos están configurados como queremos. Nunca hemos emitido un
cheque de nómina atrasado”.
Describa cómo analizaría las necesidades de almacenamiento
de datos de la empresa Marc Schneider Janitorial Supply Company.
¿Desecharía el sistema antiguo o simplemente lo puliría un poco?
Describa las implicaciones de su decisión en dos párrafos.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 405
Realidad
Datos
Metadatos Definiciones de
elementos de datos
Definiciones
de registros
Ocurrencias de
elementos de datos
Ocurrencias
de registros
AtributosEntidades
FIGURA 13.1
Realidad, datos y metadatos.
Realidad, datos y metadatos
Nos referiremos al mundo real como la realidad. Los datos que se recopilen sobre personas, lugares o eventos en
la realidad se almacenarán en un momento dado en un archivo o en una base de datos. Para comprender la forma
y estructura de los datos, se requiere información sobre los datos en sí. La información que describe a los datos
se denomina metadatos.
En la figura 13.1 se muestra la relación entre realidad, datos y metadatos. Dentro del ámbito de la realidad
están las entidades y los atributos; dentro del ámbito de los datos reales están las ocurrencias de registros y las ocu-
rrencias de elementos de datos; y dentro del ámbito de los metadatos están las definiciones de registros y las defini-
ciones de elementos de datos. En las siguientes subsecciones hablaremos sobre el significado de estos términos.
ENTIDADES Cualquier objeto o evento sobre el que alguien decida recolectar datos es una entidad. También
puede ser una persona, lugar o cosa (por ejemplo, un vendedor, una ciudad o un producto). Una entidad puede
ser también un evento o unidad de tiempo, como la descompostura de una máquina, una venta, un mes o un año.
Además de las entidades que vimos en el capítulo 2 hay una entidad menor adicional, conocida como subtipo de
entidad; se representa con un rectángulo más pequeño dentro del rectángulo de entidad.
Un subtipo de entidad es una relación especial de uno a uno empleada para representar los atributos (cam-
pos) adicionales de otra entidad que tal vez no estén presentes en todos los registros de la primera entidad. Los
subtipos de entidades eliminan la situación en la que una entidad puede tener campos nulos almacenados en ta-
blas de bases de datos.
Un ejemplo es la entidad primaria de un cliente. Los clientes preferidos pueden tener campos especiales que
contengan información de descuento; esta información se coloca en un subtipo de entidad. Otro ejemplo son los
estudiantes que tienen prácticas. El ARCHIVO MAESTRO DE ESTUDIANTES no debería contener informa-
ción sobre las prácticas para cada estudiante, ya que tal vez sólo un pequeño número de ellos las tengan.
RELACIONES Las relaciones son asociaciones entre entidades (algunas veces se les conoce como asociaciones de
datos). La figura 13.2 es un diagrama entidad-relación (E-R) que muestra varios tipos de relaciones.
El primer tipo de relación es una relación de uno a uno (se designa como 1:1). El diagrama muestra que sólo
hay un PAQUETE DE PRODUCTO para cada PRODUCTO. La segunda relación de uno a uno muestra que cada
EMPLEADO tiene una OFICINA única. Cabe mencionar que todas esas entidades se pueden describir con más
detalle (un precio de producto no sería una entidad; tampoco lo sería una extensión telefónica).
Otro tipo de relación es la asociación de uno a muchos (1:M) o de muchos a uno. Como se muestra en la
figura, a un MÉDICO en una organización al cuidado de la salud se le asignan muchos PACIENTES, pero un
PACIENTE se asigna a un solo MÉDICO. Otro ejemplo muestra que un EMPLEADO es miembro de sólo
un DEPARTAMENTO, pero cada DEPARTAMENTO tiene muchos EMPLEADOS.
Por último, una relación de muchos a muchos (se designa como M:N) describe la posibilidad de que las en-
tidades puedan tener muchas asociaciones en cualquier dirección. Por ejemplo, un ESTUDIANTE puede tener
muchos CURSO(s) y al mismo tiempo un CURSO puede tener muchos ESTUDIANTE(s) inscritos en él. El se-
gundo ejemplo muestra que un VENDEDOR puede llamar a muchas CIUDAD(es) y una CIUDAD puede ser un
área de ventas para muchos VENDEDOR(es).
La figura 13.3 muestras los símbolos estándar para la notación de pata de cuervo, la explicación oficial de
los símbolos y lo que en realidad significan. Observe que el símbolo para una entidad es un rectángulo. Una en-
tidad se define como una clase de persona, lugar o cosa. Un rectángulo con un diamante en su interior representa
a una entidad asociativa, la cual se utiliza para unir dos entidades. Un rectángulo con un óvalo en su interior re-
presenta a una entidad atributiva, la cual se utiliza para repetir grupos.
Las demás notaciones necesarias para dibujar diagramas E-R son las conexiones, de las cuales hay cinco ti-
pos distintos. En la porción inferior de la figura se explica el significado de la notación. Cuando una línea rectawww.xlibros.com

406 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
está
asignado
a
tiene Uno a uno
(1:1)
pertenece
a
atiende
Uno a muchos
(1:M)
o
Muchos a uno
(M:1)
da
servicio
a
toma Muchos a muchos
(M:N)
Ejemplos de diagramas E-R Relaciones
Oficina
Empleado
Paquete de producto
Producto
Departamento
Médico Empleado
Vendedor
Paciente
Estudiante
Cursos Ciudad
FIGURA 13.2
Los diagramas de entidad-relación
(E-R) pueden mostrar asociaciones
de uno a uno, de uno a muchos, de
muchos a uno o de muchos a
muchos.
conecta dos entidades simples y los extremos de la línea están marcados con dos rayas pequeñas (||), existe una
relación de uno a uno. Después observará una pata de cuervo con una raya pequeña (|); cuando esta notación vincula a
las entidades, indica una relación de uno a uno o de uno a muchos (a uno o más).
Las entidades vinculadas con una línea recta más una raya corta (|) y un cero (que parece más un círculo,
O) describen una relación de uno a cero o de uno a uno (sólo cero o uno). Un cuarto tipo de vínculo para rela-
cionar entidades se dibuja con una línea recta marcada en un extremo con un cero (O) seguido de una pata de
cuervo. Este tipo muestra una relación de cero a cero, de cero a uno o de cero a muchos. Por último, una línea
recta que vincula entidades con una pata de cuervo en un extremo describe una relación a más de uno.
Una entidad puede tener una relación que se conecta a sí misma. Este tipo de relación se denomina relación
de autounión; la implicación es que debe haber una forma de vincular un registro de un archivo a otro registrowww.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 407
Entidad
Símbolo Explicación oficial Lo que realmente significa
Entidad asociativa
Entidad atributiva
Relación a 1
Relación a muchos
Relación a 0 o 1
Relación a 0 o más
Relación a más de 1
Una clase de personas, lugares o cosas
Se utiliza para unir dos entidades
Se usa para repetir grupos
Exactamente uno
Uno o más
Sólo cero o uno
Puede ser cero, uno o más
Mayor de uno
FIGURA 13.3
Los símbolos del diagrama
entidad-relación y sus
significados.
del mismo archivo. Podemos encontrar un ejemplo de relación de autounión en las simulaciones de HyperCase
que se incluyen en estos capítulos. Una tarea puede tener una tarea anterior (es decir, una que se deba completar
antes de poder empezar la tarea actual). En esta situación, un registro (la tarea actual) apunta a otro registro (la
tarea anterior) en el mismo archivo.
Las relaciones en palabras se pueden escribir a lo largo de la parte superior o lateral de cada línea conectora.
En la práctica se ve la relación en una dirección, aunque podemos escribir relaciones en ambos lados de la línea,
cada una de las cuales representa el punto de vista de una de las dos entidades (vea el capítulo 2 para obtener
más detalles sobre cómo dibujar diagramas E-R).
UN EJEMPLO DE ENTIDAD-RELACIÓN En la figura 13.4 podemos ver un ejemplo de un diagrama entidad-relación
que contiene muchas entidades, muchos tipos distintos de relaciones y numerosos atributos. El diagrama E-R
tiene que ver con un sistema de facturación, en especial con la parte del sistema relacionada con la prescripción
(por cuestión de simpleza vamos a suponer que las visitas al consultorio se manejan de una manera distinta y
están fuera del alcance de este sistema).
Las entidades son PRESCRIPCIÓN, MÉDICO, PACIENTE y COMPAÑÍA DE SEGUROS. La entidad
TRATAMIENTO no es importante para el sistema de facturación, pero forma parte del diagrama E-R debido a
que se utiliza como puente para PRESCRIPCIÓN y PACIENTE. Por lo tanto la dibujamos como entidad asocia-
tiva en la figura.
Aquí, un MÉDICO atiende a muchos PACIENTE(s) (1:M), cada uno de los cuales está suscrito a una COM-
PAÑÍA DE SEGUROS individual. Desde luego que el PACIENTE es sólo uno de los muchos pacientes que se
suscriben a esa COMPAÑÍA DE SEGUROS (M:1) específica.
Para completar los registros del MÉDICO, éste necesita mantener información sobre los tratamientos que
ha llevado un PACIENTE. Muchos PACIENTE(s) experimentan muchos TRATAMIENTO(s), lo cual la con-www.xlibros.com

408 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
atiendees atendido
por
asegura
se
suscribe
a
experimenta
se aplica a
(Nombre-médico,
Dirección-médico,
Teléfono-médico,
Especialidad)
(Nombre-paciente,
Dirección-paciente,
Teléfono-paciente,
Fecha-primera-visita)
incluye
pertenece
a
(Nombre-producto,
Nombre-paciente,
Descripción,
Fecha,
Síntoma)
(Nombre-producto,
Dosis,
Fabricante,
Cantidad)
(Nombre-aseguradora,
Dirección-aseguradora,
Descripción-plan)
Médico
Paciente
Prescripción
Tratamiento
Aseguradora
FIGURA 13.4
El diagrama entidad-relación para
el tratamiento de pacientes. Los
atributos se pueden enlistar en un
lado de las entidades. En cada
caso, la clave está subrayada.
vierte en una relación de muchos a muchos (M:N). El TRATAMIENTO se representa como una entidad aso-
ciativa debido a que no es importante en nuestro sistema de facturación por sí solo. Los TRATAMIENTO(s)
pueden incluir tomar PRESCRIPCIÓN(es), por lo cual también es una relación M:N debido a que muchos tra-
tamientos pueden requerir combinaciones de farmacéuticos y muchos fármacos pueden funcionar para muchos
tratamientos.
Después se llenan ciertos detalles para los atributos. Éstos se enlistan a un lado de cada una de las entidades
y se subraya la clave. Por ejemplo, la entidad PRESCRIPCIÓN tiene NOMBRE PRODUCTO, DOSIS, FABRI-
CANTE y CANTIDAD. En teoría sería benéfico diseñar una base de datos de esta forma, utilizando diagramas
entidad-relación y después completando los detalles concernientes a los atributos. Esta metodología arriba-abajo
es conveniente, pero algunas veces es difícil de lograr.
ATRIBUTOS Un atributo es cierta característica de una entidad. Puede haber muchos atributos para cada
entidad. Por ejemplo, un paciente (entidad) puede tener muchos atributos tales como apellido paterno, primer
nombre, dirección, ciudad, estado, etcétera; la fecha de la última visita del paciente, así como los detalles de las
prescripciones también son atributos. Cuando construimos el diccionario de datos en el capítulo 8, el elemento
más pequeño que describimos se denominó elemento de información. Al hablar sobre archivos y bases de datos,
estos elementos de datos se denominan comúnmente elementos de datos. De hecho, los elementos de datos son
las unidades más pequeñas en un archivo o base de datos. El término elemento de datos se puede intercambiar
con la palabra atributo.
Los elementos de datos pueden tener valores. Estos valores pueden ser de longitud fija o variable; pueden
ser caracteres alfabéticos, numéricos, especiales o alfanuméricos. En la figura 13.5 encontrará ejemplos de ele-
mentos de datos y sus valores.
Algunas veces a un elemento de datos también se le conoce como campo. Sin embargo, un campo representa
algo físico, no lógico. Por lo tanto, muchos elementos de datos se pueden empaquetar en un campo; el campo se
puede leer y convertir en varios elementos de datos. Un ejemplo común de esto es guardar la fecha en un solo
campo como MM/DD/AAAA. Para ordenar el archivo por fecha, se extraen tres elementos de datos separados
del campo y se ordenan primero por AAAA, después por MM y finalmente por DD.
REGISTROS Un registro es una colección de elementos de datos que tienen algo en común con la entidad descrita.
La figura 13.6 es una ilustración de un registro con muchos elementos de datos relacionados. El registro que se
muestra es para un pedido realizado con una empresa de pedidos por correo. PEDIDO-#, APELLIDO PATERNO,
INICIAL, DIRECCIÓN CALLE, CIUDAD, ESTADO y TARJETA CRÉDITO son todos atributos. La mayoría
de los registros son de longitud fija, por lo que no hay necesidad de determinar la longitud del registro cada vez
que se utiliza.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 409
Entidad Elemento de datos Valor
Vendedor
Paquete
Pedido
Número vendedor
Nombre vendedor
Nombre empresa
Dirección
Ventas
Anchura
Altura
Longitud
Peso
Dirección postal
Dirección retorno
Producto(s)
Descripción(es)
Cantidad ordenada
Apellido paterno del cliente
Primera inicial
Dirección calle
Ciudad
Estado
Código postal
Número tarjeta crédito
Fecha en que se colocó el pedido
Cantidad
Estado
87254
Kaytell
Music Unlimited
45 Arpeum Circle
$20,765
2
16
16
3
765 Dulcinea Drive
P.O. Box 341, Spring Valley, MN
B521
Disco compacto “Mi Bella Dama”
1
Kiley
R.
765 Dulcinea Drive
La Mancha
CA
93407
65-8798-87
01/03/2010
$6.99
Pedido pendiente
FIGURA 13.5
Los valores típicos asignados a los
elementos de datos pueden ser
números, caracteres alfabéticos,
caracteres especiales y
combinaciones de los tres.
PEDIDO-# APELLIDO
PATERNO INICIAL
Registro
Clave Atributos
DIRECCIÓN CALLE CIUDAD ESTADO TARJETA CRÉDITO
FIGURA 13.6
Un registro tiene una clave
primaria y puede tener muchos
atributos.
Bajo ciertas circunstancias (por ejemplo, cuando el espacio es una prioridad) se utilizan registros de longi-
tud variable. Este tipo de registro se utiliza como alternativa para reservar una gran cantidad de espacio para el
registro más largo posible, como el número máximo de veces que haya visitado un paciente a un médico. Cada
visita contendría muchos elementos de datos que formarían parte del registro completo del paciente (o carpeta de
archivo en un sistema manual). Más adelante en el capítulo hablaremos sobre la normalización de una relación.
La normalización es un proceso que elimina a los grupos repetitivos que se encuentran en los registros de longi-
tud variable.
CLAVES Una clave es uno de los elementos de datos en un registro que se utiliza para identificarlo. Cuando una
clave identifica a un registro en forma única, se le llama clave primaria. Por ejemplo, PEDIDO-# puede ser
una clave primaria, ya que sólo se asigna un número a cada pedido del cliente. De esta forma, la clave primaria
identifica a la entidad del mundo real (pedido del cliente).
Hay que tener cuidado especial a la hora de diseñar la clave primaria. A menudo es un número secuencial o
un número secuencial con un número autoverificable (llamado dígito de verificación) al final. A veces hay cierto
significado integrado en la clave primaria, pero definir una clave primaria con base en un atributo se considera
un riesgo: si cambia el atributo, la clave primaria también cambiará y se creará una dependencia entre la clave
primaria y los datos.www.xlibros.com

410 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Un ejemplo de clave primaria basada en datos es el uso de una abreviatura de estado para el nombre de un
estado o el código de equipaje de una aerolínea para el nombre de un aeropuerto. A un atributo o colección de
atributos que pueden servir como clave primaria se le denomina clave candidata. Una clave primaria también
debe ser mínima y no debe contener atributos adicionales que sean necesarios para identificar a un registro.
A una clave se le denomina clave secundaria si no puede identificar a un registro en forma única. Las claves
secundarias pueden ser únicas o pueden identificar a varios registros en una base de datos. Las claves secundarias
se pueden utilizar para seleccionar un grupo de registros que pertenezcan a un conjunto (por ejemplo, pedidos
del estado de Virginia).
Cuando no es posible identificar a un registro en forma única mediante el uso de los elementos de datos en-
contrados en un registro, podemos construir una clave al elegir dos o más elementos de datos y combinarlos.
A esta clave se le denomina clave concatenada o compuesta. Cuando se utiliza un elemento de datos como clave
en un registro, la descripción se subraya. Por lo tanto, en el registro de PEDIDO (PEDIDO-# APELLIDO PA-
TERNO, INICIAL, DIRECCIÓN CALLE, CIUDAD, ESTADO, TARJETA CRÉDITO) la clave es PEDIDO-#.
Si un atributo es una clave en otro archivo, se debe subrayar con una línea punteada.
Algunas bases de datos permiten al desarrollador usar un identificador de objetos (OID), una clave única
para cada registro en la base de datos, no sólo en una tabla. Dado un identificador de objetos, se obtendrá un
registro sin importar la tabla en la que exista. Éste se puede incluir con un pedido o una confirmación de pago,
junto con un mensaje como: “Éste es su número de confirmación”.
METADATOS Los metadatos son datos sobre los datos del archivo o base de datos. Los metadatos describen el
nombre proporcionado y la longitud asignada a cada elemento de datos. Los metadatos también describen la
longitud y la composición de cada uno de los registros.
La figura 13.7 es un ejemplo de metadatos para una base de datos para cierto software genérico. La longitud
de cada elemento de datos se indica de acuerdo con una convención, donde 7.2 significa que se reservan siete
espacios para el número, dos de los cuales están a la derecha del punto decimal. La letra N significa “numérico”
y la A significa “alfanumérico”. La D representa a la “fecha” y se establece de manera automática en la forma
MM/DD/AAAA. Algunos programas como Microsoft Access usan inglés o español simple para los metadatos,
por lo que se utilizan palabras como text (texto), currency (moneda) y number (número). Microsoft Access pro-
vee un valor predeterminado de 50 caracteres como longitud de campo para los nombres, lo cual está bien si tra-
bajamos con sistemas pequeños, sin embargo, si va a trabajar con una base de datos extensa para un banco o una
compañía de servicios púbicos, por ejemplo, no es conveniente que dedique todo ese espacio a ese campo, pues
de lo contrario la base de datos crecería mucho y se llenaría de espacio desperdiciado. Aquí es cuando podemos
usar metadatos para planear con anticipación y diseñar una base de datos más eficiente.
Archivos
Un archivo contiene grupos de registros que se utilizan para proveer información para operaciones, planeación,
administración y toma de decisiones. Primero hablaremos sobre los tipos de archivos utilizados y después descri-
biremos las diversas formas en que se pueden organizar los archivos convencionales.
TIPOS DE ARCHIVOS Podemos usar los archivos para guardar datos durante un periodo indefinido o almacenarlos
provisionalmente con un propósito específico. Los archivos maestros y los archivos de tablas se utilizan para
almacenar datos por un periodo prolongado. Los archivos temporales por lo general se denominan archivos de
transacciones, archivos de trabajo o archivos de informes.
Archivos maestros Los archivos maestros contienen registros para un grupo de entidades. Estos atributos se
pueden actualizar con frecuencia, pero los registros en sí son relativamente permanentes. Estos archivos tienden
a tener registros extensos que contienen toda la información sobre una entidad de datos. Por lo general cada
registro contiene una clave primaria y varias claves secundarias.
Aunque el analista tiene la libertad de ordenar los elementos de datos en un archivo maestro en cualquier
orden, una disposición habitual es colocar el campo de la clave primaria primero, seguido de los elementos des-
criptivos y al último los elementos que cambian con frecuencia con base en las actividades de negocios. Ejem-
plos de un archivo maestro son los registros de pacientes, los registros de clientes, un archivo de personal y un
archivo de inventario de piezas.
Archivos de tablas Un archivo de tablas contiene los datos que se utilizan para calcular más datos o medidas de
desempeño. Un ejemplo es una tabla de las tarifas postales empleada para determinar los costos de envío de un
paquete; otro ejemplo es una tabla de impuestos. Por lo general sólo un programa lee los archivos de tablas.
Archivos de transacciones Un archivo de transacciones se utiliza para introducir las modificaciones que
actualizan el archivo maestro y producen informes. Suponga que el archivo maestro de suscriptores de un
periódico necesita actualizarse; el archivo de transacciones contendría el número de suscriptor y un código de
transacción, como E para extender la suscripción, C para cancelarla o D para cambiar la dirección. Así sólo haywww.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 411
Elemento de datos Valor
Número de vendedor
Nombre del vendedor
Nombre de la empresa
Dirección
Ventas
Anchura
Altura
Longitud
Peso
Dirección de envío
Dirección del remitente
Producto(s)
Descripción(es)
Cantidad solicitada
Apellido del cliente
Primera inicial
Dirección (calle)
Ciudad
Estado
Código postal
Número de tarjeta de crédito
Fecha en que se hizo el pedido
Cantidad
Estado
N 5
A 20
A 26
A 36
N 9.2
N 2
N 2
N 2
N 2
A 36
A 36
A 4
A 30
N 2
A 24
A 1
A 28
A 12
A 2
N 9
N 10
D 8 MM/DD/AAAA
$ 7.2
A 22
Se pueden
especificar
formatos
especiales para
los campos.
7.2 significa que el
campo contiene 7
dígitos, dos de los
cuales están a la
derecha del punto
decimal.
Campos
N Numérico
A Alfanumérico o texto
D Fecha MM/DD/AAAA
$ Moneda
M Memo
FIGURA 13.7
Los metadatos incluyen una
descripción de la apariencia
que debe tener el valor de cada
elemento de datos.
que introducir la información relevante a las necesidades de actualización; es decir, la longitud de la renovación
si es E y la dirección si es D. No se requeriría información adicional si se cancelara la suscripción. El resto de la
información ya existe en el archivo maestro. Los archivos de transacciones pueden contener varios tipos de
registros, como los tres que se utilizan para actualizar el archivo maestro de suscripciones al periódico, con un
código en el archivo de transacciones para indicar el tipo de transacción.
Archivos de informes Cuando es necesario imprimir un informe y no hay una impresora disponible (por ejemplo,
cuando está ocupada imprimiendo otros trabajos), se utiliza un archivo de informes. Al proceso de enviar la
salida a un archivo en vez de enviarla a una impresora se le conoce como puesta en cola, o “spooling”. Después,
cuando el dispositivo está listo se puede imprimir el documento. Los archivos de informes son muy útiles, ya que
los usuarios pueden llevar los archivos a otros sistemas computarizados y enviarlos como salida a dispositivos
especializados.
Bases de datos relacionales
Las bases de datos se pueden organizar en varias formas; el tipo más común es la base de datos relacional. Una
base de datos relacional está organizada en tablas representativas, lo cual minimiza la repetición de los datos, lo
cual a su vez reduce los errores y el espacio de almacenamiento.
VISTAS LÓGICAS Y FÍSICAS DE LOS DATOS A diferencia de un archivo, una base de datos está diseñada para que la
compartan muchos usuarios. Está claro que todos los usuarios ven los datos en distintas formas. Nos referiremos
a la manera en que un usuario imagina y ve los datos como vista de usuario; esto genera un inconveniente:
distintos usuarios tienen distintas vistas de usuarios. El analista de sistemas necesita examinar estas vistas y
desarrollar un modelo lógico general de la base de datos. Por último, hay que transformar el modelo lógico de la
base de datos en el correspondiente diseño de la base de datos física. El diseño físico se relaciona con la forma
en que se almacenan y relacionan los datos, así como la manera en que se accede a ellos.www.xlibros.com

412 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Informes de usuario
(Salidas en formato tabular, gráficas, etc.)
Esquema conceptual
(Modelo de diseño lógico de la base de datos)
Esquema interno
(Modelo de diseño físico de la base de datos)
Vistas de usuario o esquema de usuario
(Descripción del usuario sobre los datos que requiere)
FIGURA 13.8
El diseño de bases de datos
incluye sintetizar los informes de
los usuarios, las vistas de usuario
y los diseños lógicos y físicos.
En la literatura de bases de datos, las vistas se conocen como esquema. La figura 13.8 muestra cómo están
relacionados los informes y las vistas de usuario (esquema de usuario) con el modelo lógico (esquema concep-
tual) y el diseño físico (esquema interno).
Hay tres tipos principales de bases de datos estructuradas en forma lógica: jerárquicas, de redes y relacio-
nales. Podemos encontrar los primeros dos tipos en sistemas heredados (antiguos). En la actualidad, el analista
comúnmente diseña una base de datos relacional.
ESTRUCTURAS DE DATOS RELACIONALES Una estructura de datos relacional consiste en uno o más tablas
bidimensionales, las cuales se conocen como relaciones. Las filas de la tabla representan los registros y las
columnas contienen atributos.
La figura 13.9 muestra la estructura relacional para una base de datos de pedidos de CD musicales. Aquí se
necesitan tres tablas para: 1) describir los artículos y llevar el registro del precio actual de CD (PRECIO
ARTICULO), 2) describir los detalles del pedido (PEDIDO) y 3) identificar el estado del pedido (ESTADO AR-
TICULO).
Para determinar el precio de un artículo necesitamos conocer el número de artículo para encontrarlo en la
relación PRECIO ARTICULO. Para actualizar el número de tarjeta de crédito de G. MacRae, podemos buscar
la relación PEDIDO para MacRae y corregirla sólo una vez, incluso cuando él pidió muchos CD. Sin embargo,
para averiguar el estado de parte de un pedido debemos conocer ARTICULO-# y PEDIDO-#; después debemos
localizar esa información en la relación ESTADO PEDIDO.
La labor de mantenimiento de las tablas en una estructura relacional es bastante simple, si se le compara con
la labor de mantenimiento de una estructura jerárquica o de red. Una de las principales ventajas de las estructuras
relacionales es que las consultas ad hoc se manejan con eficiencia.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 413
B235 Guys and Dolls 8.99
B521 My Fair Lady 6.99
B894 42nd Street 10.99
B992 A Chorus Line 10.99
B235 10784 Se envió el 5/12
B235 19796 Se envió el 5/14
B235 11872 En proceso
B521 11821 En proceso
B894 11845 Pedido pendiente
B894 11872 Se envió el 5/12
B992 10784 Se envió el 5/12
10784 MacRae G 2314 Curly Circle Lincoln NE 45-4654-76
10796 Jones S 34 Dream Lane Oklahoma City OK 44-9876-74
11821 Preston R 1008 Madison Ave. River City IA 34-7642-64
11845 Channing C 454 Harmonia St. Nueva York NY 34-0876-87
11872 Kiley R 765 Dulcinea Drive La Mancha CA 65-8798-87
PEDIDO-#
APELLIDO
PATERNO
PEDIDO-#ARTICULO-# ESTADO
TITULOARTICULO-# PRECIO
DIRECCIÓN CALLE CTA COBROCIUDADI EDO
PRECIO ARTICULO
ESTADO ARTICULO
PEDIDO
FIGURA 13.9
En una estructura de datos
relacional, los datos se almacenan
en muchas tablas.
Cuando se analizan estructuras relacionales en la literatura sobre bases de datos, se utiliza con frecuencia
distinta terminología. A un archivo se le llama tabla o relación, a un registro por lo general se le denomina tupla
y al conjunto de valores de atributos se le conoce como dominio.
Para que las estructuras relacionales sean útiles y manejables, primero hay que normalizar las tablas relacio-
nales. En la siguiente sección veremos la normalización con detalles.
NORMALIZACIÓN
La normalización es la transformación de las vistas de usuario y almacenes de datos complejos en un conjunto
de estructuras de datos estables y más pequeñas. Además de ser más simples y estables, las estructuras de datos
normalizadas se pueden mantener con más facilidad que las demás estructuras.
Los tres pasos de la normalización
Empezando con una vista de usuario o con un almacén de datos desarrollado para un diccionario de datos (vea el
capítulo 8), el analista normaliza una estructura de datos en tres pasos, como se muestra en la figura 13.10. Cada
paso implica un procedimiento importante que simplifique la estructura de datos.
Es probable que la relación que se deriva de la vista de usuario o almacén de datos esté desnormalizada. El
primer paso del proceso incluye eliminar todos los grupos repetitivos e identificar la clave primaria. Para ello,
la relación necesita descomponerse en dos o más relaciones. En este punto, las relaciones tal vez ya estén en la
tercera forma normal, pero es probable que se necesiten más pasos para transformar las relaciones a la tercera
forma normal.
El segundo paso asegura que todos los atributos que no sean claves dependan por completo de la clave pri-
maria. Se eliminan todas las dependencias parciales y se colocan en otra relación.
El tercer paso elimina las dependencias transitivas. En una dependencia transitiva los atributos que no son
claves dependen de otros atributos que tampoco son claves.www.xlibros.com

414 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Paso 1 Eliminar grupos repetitivos
Paso 2 Eliminar dependencias parciales
Paso 3
Vistas de usuario
Eliminar dependencias transitivas
Relaciones en
tercera forma
normal (3NF)
Relaciones
normalizadas
(1NF)
Relación sin
normalizar
Relaciones en
segunda forma
normal (2NF)
FIGURA 13.10
La normalización de una relación
se lleva a cabo en tres pasos
principales.
Un ejemplo de normalización
La figura 13.11 es una vista de usuario para la empresa Al S. Well Hydraulic Equipment Company. El informe
muestra los siguientes elementos: 1) NUMERO-VENDEDOR, 2) NOMBRE-VENDEDOR y 3) AREA-VEN-
TAS. El cuerpo del informe muestra el 4) NUMERO-CLIENTE y el 5) NOMBRE-CLIENTE. A continuación
está el 6) NUMERO-ALMACEN que dará servicio al cliente, seguido de la 7) UBICACION-ALMACEN, que es
la ciudad en la que se encuentra la empresa. La información final contenida en la vista de usuario es 8) MONTO-
VENTAS. Las filas (una para cada cliente) en la vista de usuario muestran que los elementos 4 a 8 forman un
grupo repetido.
Si el analista estuviera usando una metodología de flujo de datos/diccionario de datos, la misma información
en la vista de usuario aparecería en una estructura de datos. La figura 13.12 muestra cómo aparecería la estruc-
tura de datos en la etapa del análisis correspondiente al diccionario de datos. El grupo repetitivo también se in-
dica en la estructura de datos mediante un asterisco (*) y el uso de sangría.
Antes de continuar, observe las asociaciones de datos de los elementos de datos de la figura 13.13. A este
tipo de ilustración se le denomina diagrama de burbuja o diagrama de modelo de datos. Cada entidad está
encerrada en una elipse; se utilizan flechas para mostrar las relaciones. Aunque es posible dibujar estas rela-
ciones con un diagrama E-R, algunas veces es más fácil usar el diagrama de burbuja más simple para modelar
los datos.
En este ejemplo hay sólo un NUMERO-VENDEDOR asignado a cada NOMBRE-VENDEDOR y esa per-
sona sólo cubrirá un AREA-VENTAS, pero cada AREA-VENTAS se puede asignar a muchos vendedores: de
aquí que se utilice la notación de doble flecha de AREA-VENTAS a NUMERO-VENDEDOR. Para cada NU-
MERO-VENDEDOR puede haber muchos NUMERO(s)-VENDEDOR(es).
También habría una correspondencia de uno a uno entre NUMERO-CLIENTE y NOMBRE-CLIENTE;
lo mismo se aplica para NUMERO-ALMACEN y UBICACION-ALMACEN. NUMERO-CLIENTE(s) sólo
tendrá un NUMERO-ALMACEN y una UBICACION-ALMACEN, pero cada NUMERO-ALMACEN o
UBICACION-ALMACEN puede atender a muchos NUMERO(s)-CLIENTE(s). Por último, para determinarwww.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 415
NÚMERO
CLIENTE VENTAS
NOMBRE
CLIENTE
NÚMERO
ALMACÉN
UBICACIÓN
ALMACÉN
Vendedor #: 3462
Nombre: Waters
Área de ventas: West
Al S. Well
Hydraulic Equipment Company
Spring Valley, Minnesota
18765 Delta Services 4 Fargo 13,540
18830 M. Levy and Sons 3 Bismarck 10,600
FIGURA 13.11
Un reporte de usuario para la
empresa Al S. Well Hydraulic
Equipment Company.
NUMERO-VENDEDOR
NOMBRE-VENDEDOR
AREA-VENTAS
NUMERO-CLIENTE* (1- )
NOMBRE-CLIENTE
NUMERO-ALMACEN
UBICACION-ALMACEN
MONTO-VENTAS
FIGURA 13.12
Para el analista sería útil una
estructura de datos (de un
diccionario de datos) al desarrollar
una base de datos.
el MONTO-VENTAS de las llamadas de un vendedor a una empresa específica, es necesario conocer tanto el
NUMERO-VENDEDOR como el NUMERO-CLIENTE.
El principal objetivo del proceso de normalización es simplificar todos los elementos de datos complejos
que se encuentran con frecuencia en las vistas de usuario. Por ejemplo, si el analista tomara la vista de usua-
rio antes descrita y tratara de crear una tabla relacional con base en ella, su apariencia sería como en la figura
13.14. Como esta relación se basa en nuestra vista de usuario inicial, nos referimos a ella como INFORME-
VENTAS.
INFORME-VENTAS es una relación sin normalizar, ya que tiene grupos repetidos. También es importante
observar que un solo atributo tal como NUMERO-VENDEDOR no puede servir como la clave. La razón es clara
si examinamos las relaciones entre NUMERO-VENDEDOR y los otros atributos en la figura 13.15. Aunque hay
una correspondencia de uno a uno entre NUMERO-VENDEDOR y dos atributos (NOMBRE-VENDEDOR y
AREA-VENTAS), existe una relación de uno a muchos entre NUMERO-VENDEDOR y los otros cinco atribu-www.xlibros.com

416 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
donde el conjunto interno de paréntesis representa el grupo repetido.
AREA-VENTAS
NOMBRE-
CLIENTE
UBICACION-
ALMACEN
UBICACION-
ALMACEN
MONTO-VENTAS
NUMERO-
VENDEDOR
NUMERO-
CLIENTE
NUMERO-
ALMACEN
NUMERO-
ALMACEN
NUMERO-
CLIENTE
NUMERO-
VENDEDOR
+
NUMERO-
CLIENTE
NOMBRE-
VENDEDOR
FIGURA 13.13
Algunas veces dibujar diagramas
de modelos de datos para las
asociaciones de datos ayudan a los
analistas a apreciar la complejidad
del almacenamiento de datos.
NUMERO
VENDEDOR
NOMBRE
VENDEDOR
AREA
VENTAS
NOMBRE
CLIENTE
NUMERO
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
MONTO
VENTAS
3462 Waters West 18765 Delta Systems 4 Fargo 13540
18830 A. Levy and Sons 3 Bismarck 10600
19242 Ranier Company 3 Bismarck 9700
3593 Dryne East 18841 R. W. Flood Inc. 2 Superior 11560
18899 Seward Systems 2 Superior 2590
19565 Stodola’s Inc. 1 Plymouth 8800
etc.
FIGURA 13.14
Si los datos se listaran en una tabla
sin normalizar, podría haber
grupos repetitivos.
tos (NUMERO-CLIENTE, NOMBRE-CLIENTE, NUMERO-ALMACEN, UBICACION-ALMACEN y MON-
TO-VENTAS).
Podemos expresar el INFORME-VENTAS mediante la siguiente notación abreviada:
VENDEDOR-CLIENTE (NUMERO-VENDEDOR,
NOMBRE-VENDEDOR, AREA
DE VENTAS
NUMERO-CLIENTE,
NOMBRE-CLIENTE,
NUMERO-ALMACEN,
UBICACION-ALMACEN,
MONTO-VENTAS)www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 417
NUMERO-
CLIENTE
NOMBRE-
CLIENTE
NOMBRE-
VENDEDOR
AREA-VENTAS
NUMERO-
ALMACEN
UBICACION-
ALMACEN
MONTO-VENTAS
NUMERO-
VENDEDOR
FIGURA 13.15
Un diagrama de modelo de datos
muestra que en la relación sin
normalizar, NUMERO-
VENDEDOR tiene una asociación
de uno a muchos con algunos
atributos.
PRIMERA FORMA NORMAL (1NF) El primer paso para normalizar una relación es eliminar los grupos repetidos.
En nuestro ejemplo, la relación sin normalizar INFORME-VENTAS se descompondrá en dos relaciones
separadas. Estas nuevas relaciones se llamarán VENDEDOR y VENDEDOR-CLIENTE.
La figura 13.16 muestra cómo se normaliza la relación INFORME-VENTAS al separar la relación en dos
nuevas relaciones. Cabe mencionar que la relación VENDEDOR contiene la clave primaria NUMERO-VENDE-
DOR y todos los atributos que no se repetían (NOMBRE-VENDEDOR y AREA-VENTAS).
La segunda relación, VENDEDOR-CLIENTE, contiene la clave primaria de la relación VENDEDOR (la
clave primaria de VENDEDOR es NUMERO-VENDEDOR) así como los atributos que formaban parte del
grupo repetido (NUMERO-CLIENTE, NOMBRE-CLIENTE, NUMERO-ALMACEN, UBICACION-ALMA-
CEN y MONTO-VENTAS). Sin embargo, conocer el NUMERO-VENDEDOR no implica que conoceremos
automáticamente el NOMBRE-CLIENTE, MONTO-VENTAS, UBICACION-ALMACEN, etcétera. En esta
relación debemos usar una clave concatenada (tanto NUMERO-VENDEDOR como NUMERO-CLIENTE) para
acceder al resto de la información. Es posible escribir las relaciones en notación abreviada, como se muestra a
continuación:
y
La relación VENDEDOR-CLIENTE es una relación en primera forma normal, pero no está en su forma ideal.
Surgen problemas debido a que algunos de los atributos no son funcionalmente dependientes de la clave prima-
VENDEDOR (NUMERO VENDEDOR,
NOMBRE-VENDEDOR, AREA VENTAS)
VENDEDOR-CLIENTE (NUMERO-VENDEDOR,
NUMERO-CLIENTE,
NOMBRE-CLIENTE,
NUMERO-ALMACEN,
UBICACION-ALMACEN,
MONTO-VENTAS)www.xlibros.com

418 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
3462 Waters West
3593 Dryne East
etc.
VENDEDOR
INFORME-VENTAS
VENDEDOR-CLIENTE
3462 18765 Delta Systems 4 Fargo 13540
3462 18830 A. Levy and Sons 3 Bismarck 10600
3462 19242 Ranier Company 3 Bismarck 9700
3593 18841 R. W. Flood Inc. 2 Superior 11560
3593 18899 Seward Systems 2 Superior 2590
3593 19565 Stodola’s Inc. 1 Plymouth 8800
etc.
NUMERO
VENDEDOR
NUMERO
VENDEDOR
NOMBRE
VENDEDOR
NOMBRE
VENDEDOR
AREA
VENTAS
AREA
VENTAS
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
MONTO
VENTAS
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
MONTO
VENTAS
NUMERO
VENDEDOR
FIGURA 13.16
La relación original sin normalizar
INFORME-VENTAS se separa en
dos relaciones, VENDEDOR
(3NF) y VENDEDOR-CLIENTE
(1NF).
ria (es decir, NUMERO-VENDEDOR, NUMERO-CLIENTE). En otras palabras, algunos de los atributos que
no son claves dependen sólo de NUMERO CLIENTE y no de la clave concatenada. El diagrama de modelo de
datos en la figura 13.17 muestra que MONTO-VENTAS depende de NUMERO-VENDEDOR y de NUMERO-
CLIENTE, pero los otros tres atributos dependen sólo de NUMERO-CLIENTE.
NOMBRE-
CLIENTE
NUMERO-
ALMACEN
UBICACION-
ALMACEN
NUMERO-
CLIENTE
MONTO-
VENTAS
NUMERO-
VENDEDOR
FIGURA 13.17
Un diagrama de modelo de datos
muestra que tres atributos son
dependientes de NOMBRE-
CLIENTE, por lo que la relación
aún no está normalizada. Tanto
NUMERO-VENDEDOR como
NUMERO-CLIENTE
tienen que buscar el MONTO-
VENTAS.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 419
SEGUNDA FORMA NORMAL (2NF) En la segunda forma normal, todos los atributos serán funcionalmente
dependientes de la clave primaria. Por lo tanto, el siguiente paso es eliminar todos los atributos parcialmente depen-
dientes y colocarlos en otra relación. La figura 13.18 muestra cómo se divide la relación VENDEDOR-CLIENTE
en dos nuevas relaciones: VENTAS y CLIENTE-ALMACEN. Estas relaciones también se pueden expresar de la
siguiente manera:
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
18765 Delta Systems 4 Fargo
18830 A. Levy and Sons 3 Bismarck
19242 Ranier Company 3 Bismarck
18841 R. W. Flood Inc. 2 Superior
18899 Seward Systems 2 Superior
19565 Stodola’s Inc. 1 Plymouth
etc.
NUMERO
VENDEDOR
NUMERO
CLIENTE
MONTO
VENTAS
NUMERO
VENDEDOR
MONTO
VENTAS
3462 18765 13540
3462 18830 10600
3462 19242 9700
3593 18841 11560
3593 18899 2590
3593 19565 8800
etc.
VENDEDOR-CLIENTE
CLIENTE-ALMACEN
VENTAS
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
FIGURA 13.18
La relación VENDEDOR-
CLIENTE se separa en una
relación llamada CLIENTE-
ALMACEN (2NF) y una relación
llamada VENTAS (1NF).
y
La relación CLIENTE-ALMACEN está en la segunda forma normal. Todavía se puede simplificar más debido
a que hay dependencias adicionales en la relación. Algunos de los atributos que no son claves dependen no sólo
de la clave primaria, sino también de un atributo que no es clave. Esta dependencia se denomina dependencia
transitiva.
La figura 13.19 muestra las dependencias en la relación CLIENTE-ALMACEN. Para que la relación asuma
la segunda forma normal, todos los atributos deben ser dependientes de la clave primaria NUMERO-CLIENTE,
como se muestra en el diagrama. Sin embargo, UBICACION-ALMACEN también depende obviamente de NU-
MERO-ALMACEN. Para simplificar esta relación se requiere otro paso.
VENTAS (NUMERO-VENDEDOR, NUMERO-
CLIENTE,
MONTO-VENTAS
ALMACEN CLIENTE (NUMERO-CLIENTE,
NOMBRE-CLIENTE,
NUMERO-ALMACEN,
UBICACION-ALMACEN)www.xlibros.com

420 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
TERCERA FORMA NORMAL (3NF) Una relación normalizada está en la tercera forma normal si todos los atributos
que no son claves son completa y funcionalmente dependientes de la clave primaria y no hay dependencias
transitivas (no claves). Al igual que en los pasos anteriores, es posible descomponer la relación CLIENTE-
ALMACEN en dos, como se muestra en la figura 13.20.
Las dos nuevas relaciones se llaman CLIENTE y ALMACEN, y se pueden escribir de la siguiente manera:
NUMERO-
CLIENTE
NOMBRE-
CLIENTE
UBICACION-
ALMACEN
NUMERO-
ALMACEN
FIGURA 13.19
Un diagrama de modelo de datos
muestra que existe una
dependencia transitiva entre
NUMERO-ALMACEN y
UBICACION-ALMACEN.
18765 Delta Systems 4
18830 A. Levy and Sons 3
19242 Ranier Company 3
18841 R. W. Flood Inc. 2
18899 Seward Systems 2
19565 Stodola’s Inc. 1
etc.
CLIENTE
CLIENTE-ALMACEN
4 Fargo
3 Bismarck
2 Superior
1 Plymouth
etc.
ALMACEN
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
NUMERO
ALMACEN
UBICACION
ALMACEN
FIGURA 13.20
La relación CLIENTE-
ALMACEN se separa en dos
relaciones llamadas CLIENTES
(1NF) y ALMACEN (1NF).
y
La clave primaria para la relación CLIENTE es NUMERO-CLIENTE y la clave primaria para la relación AL-
MACEN es NUMERO-ALMACEN.
Además de estas claves primarias, podemos identificar a NUMERO-ALMACEN como una clave externa
en la relación CLIENTE. Una clave externa es cualquier atributo que no sea clave en una relación, pero que sea
CLIENTE (NUMERO-CLIENTE, NOMBRE-CLIENTE,
NUMERO-ALMACEN)
ALMACEN (NUMERO-ALMACEN,
UBICACION-ALMACEN)www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 421
clave primaria en otra. Para designar a NUMERO-ALMACEN como clave externa en la notación anterior y en
las figuras, la pondremos subrayada: _____________.
Finalmente, la relación original sin normalizar INFORME-VENTAS se ha transformado en cuatro relacio-
nes 3NF. Al revisar las relaciones que se muestran en la figura 13.21, podemos ver que la relación individual
INFORME-VENTAS se transformó en las siguientes cuatro relaciones:
y
La tercera forma normal es adecuada para la mayoría de los problemas de diseño de bases de datos. La simplifi-
cación que se obtiene al transformar una relación sin normalizar en un conjunto de relaciones en 3NF constituye
un enorme beneficio en cuanto al tiempo que se requiere para insertar, eliminar y actualizar información en la
base de datos.
En la figura 13.22 se muestra un diagrama E-R para la base de datos. Un VENDEDOR atiende a muchos
CLIENTE(s), quienes generan VENTAS y reciben sus artículos de un ALMACEN (el ALMACEN más cercano a
su ubicación). Tome su tiempo para observar cómo se relacionan las entidades y atributos con la base de datos.
Uso del diagrama entidad-relación para determinar las claves de los registros
Podemos usar el diagrama E-R para determinar las claves requeridas para un registro o una relación de la base
de datos. El primer paso es construir el diagrama E-R e identificar una clave única (primaria) para cada entidad
NOMBRE
VENDEDOR
AREA
VENTAS
3462 Waters Oeste
3593 Dryne Este
etc.
VENDEDOR
3462 18765 13540
3462 18830 10600
3462 19242 9700
3593 18841 11560
3593 18899 2590
3593 19565 8800
etc.
VENTAS
18765 Delta Systems 4
18830 A. Levy and Sons 3
19242 Ranier Company 3
18841 R. W. Flood Inc. 2
18899 Seward Systems 2
19565 Stodola’s Inc. 1
etc.
CLIENTE
4 Fargo
3 Bismarck
2 Superior
1 Plymouth
etc.
ALMACEN
NUMERO
CLIENTE
NUMERO
CLIENTE
NOMBRE
CLIENTE
NOMBRE
ALMACEN
NOMBRE
ALMACEN
UBICACION
ALMACEN
NUMERO
VENDEDOR
NUMERO
VENDEDOR
MONTO
VENTAS
FIGURA 13.21
La base de datos completa consiste
en cuatro relaciones en 1NF
llamadas VENDEDOR, VENTAS,
CLIENTE y ALMACEN.
VENDEDOR (NUMERO-VENDEDOR, NOMBRE-VENDEDOR,
AREA-VENTAS)
VENTAS (NUMERO-VENDEDOR, NUMERO-CLIENTE,
MONTO-VENTAS)
CLIENTE (NUMERO-CLIENTE, NOMBRE-CLIENTE,
NUMERO-ALMACEN)
ALMACEN (NUMERO-ALMACEN,
UBICACION-ALMACEN)www.xlibros.com

422 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
(Numero-vendedor,
Nombre-vendedor,
Area-ventas)
genera
se
llevan a
cabo por
son
compradas
por
accede
a
recibe de
envía a
(Numero-vendedor,
Numero-cliente,
Monto ventas)
(Numero-cliente,
Nombre-cliente,
Numero-almacen)
(Numero-almacen,
Ubicacion-almacen)
Vendedor
Cliente
Ventas
Almacén
FIGURA 13.22
Un diagrama entidad-relación para
la base de datos de la empresa
Al S. Well Hydraulic Company.
coloca
Numero-cliente
contiene
Numero-pedido
Numero-cliente
Numero-Articulo
Cliente Pedido Articulo
FIGURA 13.23
Un diagrama entidad-relación para
los pedidos de los clientes.
de datos. La figura 13.23 muestra un diagrama E-R para un sistema de pedidos de clientes. Hay tres entidades de
datos: CLIENTE, con la clave primaria NUMERO-CLIENTE; PEDIDO, con la clave primaria NUMERO-
PEDIDO, y ARTICULO, con NUMERO-ARTICULO como clave primaria. Un CLIENTE puede colocar muchos
pedidos, pero cada PEDIDO puede ser colocado sólo por un CLIENTE, por lo que la relación es de uno a mu-
chos. Cada PEDIDO puede contener muchos ARTICULO(s), y cada ARTICULO puede estar contenido en muchos
PEDIDO(s), por lo que la relación PEDIDO-ARTICULO es de muchos a muchos.
Sin embargo, una clave externa es un campo de datos de cierto archivo que es la clave primaria de otro ar-
chivo maestro. Por ejemplo, un NUMERO-DEPARTAMENTO que indica que la especialidad de un estudiante
puede existir en la tabla MAESTRA DE ESTUDIANTES. NUMERO-DEPARTAMENTO también podría ser la
clave única para la tabla MAESTRA DE DEPARTAMENTOS.
Relación de uno a muchos
Una relación de uno a muchos es el tipo más común de relación, ya que todas las relaciones de muchos a muchos
se deben descomponer en dos relaciones de uno a muchos. Cuando ocurra una relación de uno a muchos, colo-
que la clave primaria de la tabla en el extremo de uno de la relación como una clave externa para la tabla en el
extremo de muchos de la relación. Por ejemplo, como un cliente puede tener muchos pedidos, coloque el número
de cliente en el registro de pedidos.
Es fácil construir el diseño de páginas Web, pantallas o informes que incluyan información de sólo un regis-
tro de la relación de muchos, junto con la información del extremo de uno de la relación. La pantalla no tendrá
información repetida. Un ejemplo es la consulta de un pedido mediante el uso de un número de pedido para bus-
car un pedido individual. Como el pedido es para un cliente, el resultado consistiría en los campos del pedido y
un solo cliente.
Es más complicado diseñar el inverso, ya que la tabla en el extremo de uno de la relación puede tener mu-
chos registros para el extremo de muchos. Éstos se implementan en varias formas. Para una pantalla de visuali-
zación simple, la información del extremo de uno se muestra con un número repetitivo de grupos de información
del extremo de muchos de la relación. En Microsoft Access esto podría ser un formulario con un subformulario,www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 423
como un cliente con un subformulario de todos los pedidos del cliente. Si hubiera un extenso número de registros
del extremo de muchos, aparecerían barras de desplazamiento.
En situaciones simples, la relación también se podría implementar mediante el uso de una lista desple-
gable, donde cada registro del extremo de muchos se convertiría en una entrada en el extremo de uno; un
ejemplo es la pantalla de un automóvil junto con una lista desplegable que contenga todos los modelos de ese
automóvil. Al diseñar sitios Web, la información del extremo de uno podría estar en la parte superior de la
página, con varios grupos de datos debajo de ésta o varios vínculos a los datos. Un ejemplo es un tema en un
motor de búsqueda que produce como resultado muchos vínculos coincidentes, o un género de música y mu-
chos artistas que coinciden con ese género.
Relación de muchos a muchos
Cuando la relación es de muchos a muchos se requieren tres tablas: una para cada entidad de datos y una para
la relación. Las entidades PEDIDO y ARTICULO en nuestro ejemplo tienen una relación de muchos a mu-
chos. La clave primaria de cada entidad de datos se almacena como una clave externa de la tabla relacional.
Esta tabla relacional puede contener sólo las claves primarias para cada entidad de datos, o puede contener da-
tos adicionales, como la calificación recibida por un curso o la cantidad de un artículo ordenado. Consulte la
disposición de la tabla que se muestra en la figura 13.24. La tabla ARTICULO PEDIDO contiene información
sobre los artículos que contiene cada pedido y provee un vínculo entre la tabla PEDIDO y la tabla MAESTRA
DE ARTICULOS.
La tabla de relación se debe indexar en cada clave externa (una para cada tabla en la relación) y puede tener
una clave primaria que consista en una combinación de las dos claves externas. A menudo las empresas usan una
clave única, como un número de secuencia, como la clave primaria para la tabla relacional. Para buscar muchos
registros de una segunda tabla dada la primera, lea directamente la tabla relacional en busca de la clave deseada.
Localice el registro que coincida en la segunda tabla de muchos. Siga iterando por la tabla relacional hasta que
ya no encuentre la clave deseada. Por ejemplo, para buscar los registros en la tabla MAESTRA DE ARTICU-
LOS para un registro específico en la tabla PEDIDO, lea directamente la tabla PEDIDO-ARTICULO usando el
NUMERO-PEDIDO como índice. Los registros se secuencian en forma lógica con base en los datos del índice,
por lo que todos los registros para el mismo NUMERO-PEDIDO se agrupan entre sí. Para cada registro de PE-
DIDO-ARTICULO que coincida con el NUMERO-PEDIDO deseado, lea directamente la tabla MAESTRA DE
ARTICULOS usando el NUMERO-ARTICULO como índice.
La lógica es la misma para la situación inversa, como buscar en todos los pedidos un artículo pendiente que
se haya recibido. Use el NUMERO-ARTICULO deseado para leer la tabla PEDIDO-ARTICULO directamente.
El índice de PEDIDO-ARTICULO se establece en el NUMERO-ARTICULO. Para todos los registros de PEDI-
DO-ARTICULO que coincidan, use el NUMERO-PEDIDO para leer la tabla PEDIDO directamente. Por último,
lea la tabla MAESTRA DE CLIENTES directamente para obtener el NOMBRE-CLIENTE y DIRECCION me-
diante el uso del NUMERO-CLIENTE en la tabla PEDIDO.
Las tablas relacionales pueden tener relaciones con más tablas en la base de datos además de las dos con las
que se conectan directamente. Por ejemplo, podría haber una tabla relacional llamada Clase o Seccion para vincular
estudiantes y cursos, ya que cada estudiante puede tomar muchos cursos y cada curso puede tener muchos estu-
diantes. La tabla Seccion puede tener una relación con el Librotexto o Instructor para esa sección.
NUMERO
PEDIDO
NUMERO
CLIENTE
FECHA
PEDIDO
CANTIDAD
ORDENADA
NUMERO
ARTICULO
DESCRIPCION
ARTICULO
COSTO
ARTICULO
PRECIO
ARTICULO
CANTIDAD
DISPONIBLE
PEDIDO
PEDIDO-ARTICULO
MAESTRA DE ARTICULOS
NUMERO
PEDIDO
NUMERO
ARTICULO
PEDIDO-
ARTICULO sirve
como vínculo.
FIGURA 13.24
Cuando la relación es de muchos a
muchos se necesitan tres archivos.www.xlibros.com

424 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
LINEAMIENTOS PARA EL DISEÑO DE RELACIONES DE ARCHIVOS
MAESTROS/BASES DE DATOS
Hay que tener en consideración los siguientes lineamientos al diseñar relaciones de archivos maestros o bases de
datos:
1. Cada entidad de datos separada debe crear una tabla maestra de base de datos. No debe combinar dos
entidades distintas en un archivo. Por ejemplo, los artículos se compran de los distribuidores. La tabla
MAESTRA DE ARTICULOS debe contener sólo información de los artículos y la tabla MAESTRA DE
DISTRIBUIDORES debe contener sólo información de los distribuidores.
2. Un campo de datos específico debe existir sólo en una tabla maestra. Por ejemplo, el NOMBRE CLIENTE
podría existir sólo en la tabla MAESTRA DE CLIENTES, no en la tabla PEDIDO o en ninguna otra tabla
maestra. Las excepciones a este lineamiento son los campos claves o índices, que pueden estar en todas las
tablas que sea necesario. Si un informe o pantalla necesita información de muchas tablas, los índices deben
proveer los vínculos para obtener los registros requeridos.
3. Cada relación de tabla maestra o base de datos debe tener programas para crear (C), leer (R), actualizar (U)
y eliminar (D) registros (lo cual se abrevia como CRUD). En teoría sólo un programa debería agregar nuevos
registros y sólo un programa debería eliminar registros especificados. Sin embargo, muchos programas
pueden ser responsables de modificar los campos de datos en el curso de las actividades de negocios
normales. Por ejemplo, un archivo MAESTRO DE CLIENTES podría tener un campo SALDO ACTUAL
que aumente en base al TOTAL PEDIDO en el programa de procesamiento de pedidos y disminuya con base
en un MONTO PAGO o a un MONTO DEVUELTO que provengan de dos programas adicionales.
Restricciones de integridad
Las restricciones de integridad son reglas que gobiernan las acciones de modificar y eliminar registros, y que
ayudan a mantener la precisión de los datos en la base de datos. Podemos aplicar tres tipos de restricciones de
integridad a una base de datos:
1. Integridad de entidad.
2. Integridad referencial.
3. Integridad de dominio.
Las restricciones de integridad de entidad son reglas que gobiernan la composición de claves primarias. La clave
primaria no puede tener un valor nulo; si la clave primaria es una clave compuesta, ninguno de los campos que
componen la clave puede contener un valor nulo. Algunas bases de datos nos permiten definir una restricción
única o una clave única. Esta clave única sólo identifica un registro que no es una clave primaria. La diferencia
ente una clave única y una clave primaria es que una clave única puede contener un valor nulo.
La integridad referencial gobierna la naturaleza de los registros en una relación de uno a muchos. La tabla
que está conectada en el extremo de uno de la relación se llama padre. La tabla conectada al extremo de muchos
de la relación se llama tabla hija. Integridad referencial significa que todas las claves externas en la tabla de mu-
chos (la tabla hija) deben tener un registro que coincida en la tabla padre. Por ende, no podemos agregar un re-
gistro en la tabla hija (muchos) sin un registro que coincida en la tabla padre.
Una segunda implicación es que no podemos cambiar una clave primaria que tenga registros que coincidan
en la tabla hija. Si pudiéramos cambiar el registro padre, el resultado sería un registro hijo que tendría un distinto
registro padre o un registro huérfano, o un registro hijo sin un registro padre. Algunos ejemplos son un registro
CALIFICACION para un estudiante que no estuviera en la tabla MAESTRA DE ESTUDIANTES y un registro PE-
DIDO para un NUMERO CLIENTE inexistente. La última implicación de la integridad referencial es que no
podemos eliminar un registro padre que tenga registros hijos. Eso también produciría los registros huérfanos que
mencionamos antes.
La integridad referencial se implementa de dos formas. La primera es tener una base de datos restringida, en
la cual el sistema pueda actualizar o eliminar un registro padre sólo si no hay registros hijos que coincidan. Una
base de datos en cascada eliminará o actualizará todos los registros hijos cuando se elimine o modifique un regis-
tro padre (el padre desencadena los cambios).
Es mejor una relación restringida al eliminar registros. ¡No sería conveniente eliminar un registro de un
cliente y eliminar también todas las facturas pendientes! La metodología en cascada es mejor a la hora de modi-
ficar registros. Si se modifica la clave primaria del registro de un estudiante, se modificarían también las claves
externas (el NUMERO ESTUDIANTE en la tabla MAESTRA DE CURSOS) en todos los registros de cursos
para ese estudiante.
Las reglas de integridad de dominio se utilizan para validar los datos, como las comprobaciones de valida-
ción de tabla, límite, rango, etcétera. En el capítulo 15 explicaremos estas reglas con más detalle. Por lo gene-www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 425
ral, las reglas de dominio de integridad se almacenan en la estructura de la base de datos en una de dos formas.
Las restricciones de verificación se definen a nivel de tabla y pueden hacer referencia a uno o más campos en
la tabla. Un ejemplo es que la FECHA DE COMPRA siempre es menor o igual a la fecha actual. Las reglas se
definen a nivel de base de datos con objetos separados y se pueden utilizar con varios campos. Un ejemplo es un
valor mayor a cero que se utilice para validar varios elementos.
Anomalías
Pueden ocurrir cuatro anomalías al crear tablas de bases de datos:
1. Redundancia de datos.
2. Anomalía de inserción.
3. Anomalía de eliminación.
4. Anomalía de actualización.
La redundancia de los datos ocurre cuando se almacenan los mismos datos en más de un lugar en la base
de datos (exceptuando las claves primarias que se almacenan como claves externas). Para resolver este problema
hay que crear tablas que estén en 3NF.
A T R A C T I V O D E L A M A C
Aunque Microsoft Word, Excel y PowerPoint están disponibles para el sistema operativo de la Mac, la única forma de
ejecutar Microsoft Access es ejecutar Windows en modo de virtualización o iniciar directamente en Windows. Existen
otras dos opciones para la Mac: Bento y FileMaker Pro. Bento es una base de datos personal que permite a los usuarios
recopilar información en forma eficiente de la libreta de direcciones, la aplicación de calendario, Apple Mail y Micro-
soft Excel; después podemos agregar campos al instante para crear una base de datos personalizable.
Tal vez algunos usuarios encuentren a Bento algo limitante; para estos casos está el hermano mayor de Bento,
FileMaker Pro. Éste es un programa completo de bases de datos relacionales que proporciona acceso directo a bases de
datos de SQL. Su característica distintiva es que las pantallas, los formularios y los informes para acceder a la base de datos
están completamente integrados con el motor de bases de datos.
FIGURA 13.MAC
Ejemplo de pantalla de Bento, una base de datos personal. Esta pantalla se utilizó con
permiso de FileMaker, Inc.www.xlibros.com

426 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Una anomalía de inserción ocurre cuando no se conoce toda la clave primaria y la base de datos no puede
insertar un nuevo registro, el cual violaría la integridad de entidad. Este problema ocurre por lo general cuando la
clave primaria es una clave compuesta que contiene varios atributos más pequeños. Para evitar una anomalía de
inserción hay que utilizar un número de secuencia para la clave primaria.
Una anomalía de eliminación ocurre cuando se elimina un registro y como resultado se pierden otros da-
tos relacionados. Un ejemplo es cuando un artículo tiene un número de distribuidor y ese artículo específico
es la única referencia a cierto distribuidor. Si se elimina ese artículo, no habría referencia al registro del dis-
tribuidor.
Una anomalía de actualización se produce cuando un cambio en el valor de un atributo ocasiona que la base
de datos contenga datos inconsistentes o haya que modificar varios registros. Un ejemplo es cuando cambia el
nombre de una calle en una ciudad. Podríamos cambiar algunos de los nombres de las calles y otros no, o ten-
dríamos que asegurarnos que se hayan cambiado los nombres de todas las calles. Esto puede ocurrir cuando hay
dependencias transitivas y podemos prevenirlo mediante la creación de tablas que estén en 3NF (aunque en el
ejemplo de la calle, tal vez los datos estén en 3NF).
USO DE LA BASE DE DATOS
Hay varios pasos que debemos llevar a cabo en orden secuencial para asegurar que la base de datos sea útil para
presentar los datos.
Pasos para recuperar y presentar los datos
Hay ocho pasos en el proceso de recuperación y presentación de los datos:
1. Seleccionar una relación de la base de datos.
2. Unir las relaciones.
3. Proyectar las columnas de la relación.
4. Seleccionar filas de la relación.
5. Derivar nuevos atributos.
6. Indexar u ordenar filas.
7. Calcular totales y medidas de desempeño.
8. Presentar los datos.
Hay que llevar a cabo los pasos primero y último, pero los seis pasos intermedios son opcionales, dependiendo
de la forma en que se vayan a usar los datos. La figura 13.25 es una guía visual para los pasos.
El paso final en la recuperación de los datos es la presentación. Podemos presentar los datos que se abstraen
de la base de datos en muchas formas. Algunas veces se presentan en formato tabular, algunas veces en gráficos
y otras como una respuesta de una sola palabra en pantalla. El diseño de la salida, como vimos en el capítulo 11,
provee un análisis más detallado sobre los objetivos, formas y métodos de presentación.
DESNORMALIZACIÓN
Una de las principales razones de la normalización es organizar los datos de manera que se reduzcan los datos
redundantes. Si no tenemos que almacenar los mismos datos una y otra vez, podemos ahorrar mucho espacio.
Dicha organización permite al analista reducir la cantidad de almacenamiento necesario, algo que era muy im-
portante cuando el almacenamiento era costoso.
En la última sección aprendimos que para usar datos normalizados tuvimos que progresar por una serie de
pasos que involucran la unión, el ordenamiento y la síntesis. Cuando la velocidad de consultar la base de datos
(es decir, hacer una pregunta y requerir una respuesta rápida) es crítica, tal vez sea importante almacenar los da-
tos de otras formas.
La desnormalización es el proceso de tomar el modelo de datos lógico y transformarlo en un modelo físico
que sea eficiente para las tareas requeridas con más frecuencia. Estas tareas pueden incluir la generación de in-
formes, pero también pueden implicar consultas más eficientes. Las consultas complejas como el procesamiento
analítico en línea (OLAP), así como los procesos de minería de datos y descubrimiento de conocimiento en bases
de datos (KDD), también pueden usar bases de datos que estén desnormalizadas.
Podemos llevar a cabo la desnormalización de varias formas. La figura 13.26 muestra uno de los métodos.
Primero podemos tomar una relación de muchos a muchos, como la de VENDEDOR y CLIENTE, que compar-
ten la entidad asociativa VENTAS. Al combinar los atributos de VENDEDOR y VENTAS podemos evitar uno
de los procesos de unión. Esto puede producir una cantidad considerable de duplicación de datos, pero mejora la
eficiencia de las consultas sobre los patrones de ventas.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 427
Otra de las razones de desnormalizar es evitar la referencia repetida a una tabla de búsqueda. Tal vez sea
más eficiente repetir la misma información (por ejemplo: ciudad, estado y código postal) incluso si por lo gene-
ral esta información se puede almacenar sólo como un código postal. Por ende, en el ejemplo de ventas podría-
mos combinar CLIENTE y ALMACEN.
Finalmente veremos las relaciones de uno a uno, ya que es muy probable que se combinen por razones prác-
ticas. Si descubrimos que muchas de las consultas relacionadas con los pedidos también se interesan en saber
cómo se envió el pedido, sería conveniente combinar, o desnormalizar. Así, en el ejemplo algunos de los detalles
pueden aparecer tanto en DETALLES-PEDIDO como en DETALLES-ENVIO al llevar a cabo la desnormaliza-
ción.
Seleccionar una(s)
relación(es) de la base
de datos.
Unir las relaciones.
Proyectar las columnas
de la relación.
Seleccionar filas de
la relación.
Derivar nuevos atributos.
Indexar u ordenar las filas.
Calcular los totales y las
medidas de desempeño.
Presentar los datos.INFORME
FIGURA 13.25
Los datos se obtienen y presentan
en ocho pasos.www.xlibros.com

428 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
VENDEDOR
NUMERO
VENDEDOR
NOMBRE
VENDEDOR
AREA
VENTAS
VENTAS-VENDEDOR-DESNORMALIZADA
NUMERO
VENDEDOR
NUMERO
CLIENTE
NUMERO
CLIENTE
MONTO
VENTAS
VENTAS
NUMERO
ALMACEN
UBICACION
ALMACEN
ALMACEN
NUMERO
CLIENTE
NOMBRE
CLIENTE
MONTO
VENTAS
NUMERO
ALMACEN
CLIENTE
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
ALMACEN
UBICACION
ALMACEN
CLIENTE-DESNORMALIZADA
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
PEDIDO
FECHA
PEDIDO
MONTO
PEDIDO
DETALLES-PEDIDO
DETALLES-PEDIDOS-DESNORMALIZADA
NUMERO
ENVIO
NOMBRE
ENVIO
DIRECCION
ENVIO
FECHA
ENVIO
METODO
ENVIO
NUMERO
CLIENTE
DETALLES-ENVIO
NUMERO
ENVIO
NOMBRE
ENVIO
DIRECCION
ENVIO
FECHA
ENVIO
METODO
ENVIO
NUMERO
CLIENTE
DETALLES-ENVIO-DESNORMALIZADA
NUMERO
PEDIDO
FECHA
PEDIDO
Combinación de
una entidad con
una entidad
asociativa
Combinación de
relaciones 1:1
Combinación de
tablas de
búsqueda
NUMERO
VENDEDOR
NOMBRE
VENDEDOR
AREA
VENTAS
NUMERO
CLIENTE
NOMBRE
CLIENTE
NUMERO
PEDIDO
FECHA
PEDIDO
MONTO
PEDIDO
NUMERO
ENVIO
NOMBRE
ENVIO
DIRECCION
ENVIO
FECHA ENVIO
FIGURA 13.26
Tres ejemplos de
desnormalización para hacer el
acceso más eficiente.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 429
ALMACENES CORPORATIVOS DE DATOS
Los almacenes corporativos de datos son distintos de las bases de datos tradicionales. El propósito de un almacén
corporativo de datos es organizar la información para consultas rápidas y efectivas. Es cierto que almacenan da-
tos desnormalizados, pero van un paso más allá. Organizan los datos con base en los temas. En la mayoría de los
casos el almacén corporativo de datos es más que una base de datos que se procesa de manera que los datos se
representen en maneras uniformes. Por lo tanto, los datos almacenados en los almacenes de datos provienen de
distintas fuentes, por lo general bases de datos que se establecieron para distintos fines.
El concepto de almacén corporativo de datos es único. Las diferencias entre los almacenes corporativos de
datos y las bases de datos tradicionales incluyen lo siguiente:
1. En un almacén corporativo de datos, los datos se organizan con base en los temas principales en vez de las
transacciones individuales.
2. Por lo general, los datos en un almacén corporativo de datos se organizan como datos sintetizados en vez de
los datos puros detallados que se encuentran en una base de datos orientada a transacciones.
3. Los datos de un almacén corporativo de datos cubren un marco de tiempo mucho mayor que los datos en las
bases de datos tradicionales orientadas a transacciones, ya que comúnmente las consultas se relacionan con
la toma de decisiones a largo plazo, en vez de los detalles diarios de las transacciones.
4. La mayoría de los almacenes corporativos de datos se organizan para consultas rápidas, mientras que las
bases de datos más tradicionales están normalizadas y estructuradas de tal forma que provean un
almacenamiento eficiente de la información.
5. Por lo general, los almacenes corporativos de datos están optimizados para responder consultas complejas de los
gerentes y analistas conocidas como OLAP, en vez de las consultas simples que se realizan en forma repetida.
6. Los almacenes corporativos de datos permiten un fácil acceso a través de software de minería de datos
(conocido como siftware), el cual busca patrones y puede identificar las relaciones que los humanos
encargados de tomar decisiones no imaginan.
7. Los almacenes corporativos de datos no sólo incluyen una, sino varias bases de datos que se han procesado
de manera que los datos del almacén corporativo se definan con uniformidad. Estas bases de datos se
conocen como datos limpios.
8. Comúnmente los almacenes corporativos de datos incluyen información de fuentes externas (como un
informe industrial, el archivo de la empresa en la Comisión de Bolsa y Valores, o incluso información sobre
los productos de los competidores), así como datos generados para uso interno.
El proceso de crear un almacén corporativo de datos es una tarea monumental. El analista necesita recopilar datos
de una variedad de fuentes y traducir esos datos a una forma común. Por ejemplo, tal vez una base de datos almacene
información sobre los géneros como “Masculino” y “Femenino”, otra la almacene como “M” y “F”, y una tercera la
almacene como “1” y “0”. El analista necesita establecer un estándar y convertir todos los datos al mismo formato.
Una vez que están limpios los datos, el analista debe decidir cómo sintetizarlos. Una vez sintetizados se pier-
den los detalles, por lo que el analista tiene que predecir el tipo de consultas que se podrían realizar.
Después, el analista necesita diseñar el almacén corporativo de datos mediante la organización lógica (y tal
vez el agrupamiento físico) de los datos por tema, lo cual requiere de mucho análisis y diseño. El analista nece-
sita conocer mucho sobre la empresa.
El tamaño de los almacenes corporativos de datos ordinarios tiende a estar entre los 50 gigabytes hasta de-
cenas de terabytes. Como son grandes, también son costosos. La mayoría de los almacenes corporativos de datos
cuestan millones de dólares.
Procesamiento analítico en línea
El procesamiento analítico en línea (OLAP) fue introducido por E. F. Codd en 1993. Su objetivo era responder a
las preguntas complejas de los encargados de tomar decisiones. Codd concluyó que el encargado de tomar deci-
siones tenía que analizar los datos en distintas formas. Por lo tanto, la base de datos en sí tenía que ser multidi-
mensional. Muchas personas consideran que OLAP es el Cubo de Rubik de los datos. Se pueden ver los datos de
todos los distintos lados y también se pueden manipular al girarlos o torcerlos, para que tengan sentido.
Esta metodología OLAP validó el concepto de los almacenes corporativos de datos. Después surgió la ne-
cesidad de organizar los datos en formas que permitieran consultas eficientes. Desde luego que OLAP implica
el procesamiento de los datos por medio de manipulación, síntesis y cálculo, por lo que hay más de un almacén
corporativo de datos involucrado.
Minería de datos
La minería de datos puede identificar patrones que un humano no puede. O el encargado de tomar decisiones
no puede ver un patrón, o tal vez no puede pensar en preguntar si existe ese patrón. Los algoritmos de minería
de datos buscan patrones en los almacenes corporativos de datos mediante el uso de algoritmos. La figura 13.27
ilustra el concepto de minería de datos.www.xlibros.com

430 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U L T O R Í A 1 3 . 2
Almacenamiento de minerales para la salud, minería de datos
Esther See, una de las empleadas de Marathon Vitamin Shop, se
acerca al propietario Bill Berry para comentarle: “He observado que
nuestros clientes tienen distintos hábitos. Algunos vienen con regu-
laridad y otros son menos predecibles”, dice Esther. “Cuando veo a
un cliente regular, me enorgullezco de anticipar lo que el cliente va
a comprar e incluso hasta puedo sugerirle otras vitaminas de su
agrado. Creo que genero más ventas de esa forma. Además, el
cliente está más contento”.
Esther continúa: “Aunque desearía poder ayudar mejor a algu-
nos de los clientes que vienen con menos frecuencia”.
“Es una actitud muy favorable, Esther, además de que ayuda a
nuestra tienda”, le responde Bill. “Sé que podemos beneficiarnos de
otras formas si logramos manejar mejor los patrones de los clientes. Por
ejemplo, podemos estar seguros de tener un artículo en existencia”.
Ester asiente y agrega: “No es sólo el tipo de vitamina de lo que
estoy hablando. Algunos clientes prefieren una marca en vez de otra.
No sé si depende de su nivel de ingreso o de los intereses que tengan
en actividades de esparcimiento. Como los deportes, por ejemplo”.
“Ya veo, Srita. See” dice Bill sonriendo, “¿tiene algo en
mente?”.
“Sí, Sr. Berry”, dice en un tono más formal. “Deberíamos or-
ganizar los datos que tenemos sobre nuestros clientes mediante el
concepto de un almacén corporativo de datos. Podemos fusionar los
datos que tenemos con la información de otras fuentes. Así pode-
mos buscar patrones en nuestros datos. Tal vez podamos identificar
los patrones existentes y predecir nuevas tendencias”.
Piense cómo organizaría un almacén corporativo de datos para
Marathon Vitamin Shops. ¿Qué otras bases de datos le gustaría fu-
sionar en el almacén de datos? ¿Qué tipo de patrones debería estar
buscando Bill Berry? Identifique estos patrones por tipo (asociacio-
nes, secuencias, agrupamiento o tendencias) y descríbalos en uno o
dos párrafos.
La minería de datos se conoce también por otro nombre: descubrimiento de conocimiento en bases de da-
tos (KDD). Algunos piensan que KDD es distinto a la minería de datos, debido a que su objetivo es ayudar a
los encargados de tomar decisiones a encontrar patrones, en vez de ceder el control a un algoritmo para que los
encuentre. Las ayudas disponibles para las decisiones se conocen como siftware; incluyen el análisis estadístico,
los árboles de decisión, las redes neurales, los agentes inteligentes, la lógica difusa y la visualización de datos.
Datos
externos
Datos que se
mantienen en
forma interna
Prospectos/listas
de correo de otras
empresas
Historial de compras
del cliente con su
tarjeta de crédito
Datos demográficos
del cliente procedentes
de la municipalidad
Tarjeta de
garantía que envió
el cliente Información de
la encuesta que
llenó el cliente
Perfil de cliente que
se obtuvo cuando
el cliente hizo una
compra en la WebOferta promocional
especial para
el cliente
Datos
externos
Datos
externos
Customer Process 1
Customer Order
Contains customer order information and is used to update the
customer master and item files and to produce an order record.
ID
Name
Description
Comments
Source Destination
Type of Data Flow
File Screen Report Form Internal
Data Structure Traveling with the Flow Volume/Time
Order Information 10/hour
An order record information for one customer order. The order
may be received by mail, by FAX, or by the customer telephoning the order
processing department directly.
FIGURA 13.27
La minería de datos recopila
información personal sobre los
clientes, en un esfuerzo por ser
más específicos al interpretar y
anticiparse a sus preferencias.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 431
Los tipos de patrones que los encargados de tomar decisiones tratan de identificar incluyen las asociacio-
nes, las secuencias, el agrupamiento y las tendencias. Las asociaciones son patrones que ocurren en conjunto al
mismo tiempo. Por ejemplo, una persona que compra cereal por lo general compra leche para acompañarlo. Por
otro lado, las secuencias son patrones de acciones que se llevan a cabo durante un periodo de tiempo. Por ejem-
plo, si una familia compra una casa este año, es muy probable que vayan a comprar bienes de consumo durade-
ros (un refrigerador, o lavadora y secadora) el próximo. El agrupamiento es el patrón que se desarrolla entre un
grupo de personas. Por ejemplo, los clientes que viven en un código postal específico tal vez tiendan a comprar
un automóvil específico. Por último, las tendencias son patrones que se observan durante un periodo de tiempo.
Por ejemplo, tal vez los consumidores pasen de comprar artículos genéricos a productos premium.
El concepto de minería de datos surgió del deseo de usar una base de datos para una focalización más selec-
tiva de los clientes. Las primeras metodologías para el correo directo incluían el uso de la información del código
O P O R T U N I D A D D E C O N S U L T O R Í A 1 3 . 3
Pérdida de prospectos
“La participación en el mercado puede ser un verdadero pro-
blema”, dice Ryan Taylor, director de sistemas de marketing para
una aseguradora médica de la Costa Este de Estados Unidos. “Uno
de los mayores retos al que hacemos frente es cómo identificar
buenos prospectos para nuestros vendedores. Con más del 50 por
ciento de participación en el mercado, debemos eliminar los nom-
bres de la mayoría de los prospectos que compramos antes de llenar
nuestra base de datos de marketing; es imprescindible que lo haga-
mos bien, ya que ésta es parte crucial de nuestro arsenal de herra-
mientas de información estratégica de la empresa”.
Ryan explica a Chandler, uno de los miembros del equipo de
analistas de sistemas que usted dirige: “Una base de datos de mar-
keting, o MDB para abreviar, es una poderosa base de datos relacio-
nal que representa el corazón de los sistemas de marketing. Nuestra
base de datos de marketing se utiliza para proveer información para
todos los sistemas de marketing. En estos sistemas se incluyen las
herramientas de productividad, como nuestra Automatización de
las fuerzas de ventas y nuestros Sistemas de correo masivo, diseña-
dos para ayudar a los vendedores a administrar el ciclo de ventas.
También se incluyen las herramientas analíticas, como nuestros
sistemas de información geográfica (GIS) o las herramientas del
lenguaje gráfico de consulta (CQL), que están diseñadas para pro-
veer soporte para las decisiones.
“Pero la principal función de una base de datos de marketing es
rastrear la información sobre nuestros clientes y prospectos. En la
actualidad rastreamos la información geográfica, demográfica y psi-
cográfica o, como me gusta decirlo, dónde viven, quiénes son y cómo
piensan”.
“Las bases de datos de marketing más simples se pueden crear
a partir de sólo tres archivos: Perfil de prospectos, Perfil de clientes
e Historial de compras y pagos”.
“Una vez diseñada la base de datos de marketing, el siguiente
reto es decidir cómo llenarla. En la actualidad compramos nuestra
información de prospectos a un distribuidor de listas. Como la es-
trategia de marketing de nuestra empresa se basa en el marketing en
masa, compramos todos los negocios en nuestra área. Debido a este
volumen, pagamos menos de diez centavos de dólar por cada pros-
pecto. No obstante, si una empresa practica la diferenciación de
productos, es probable que su base de prospectos sea más definida.
Esta empresa probablemente pagaría una prima por datos más deta-
llados que se validaron con cuidado”, explica Ryan.
“Nos enfrentamos a un verdadero reto. Si tuviera un dólar por
cada vez que un representante se queja conmigo sobre la dirección
equivocada de un prospecto, podría retirarme y mudarme a Flo-
rida”, bromea Ryan. “Mi trabajo es identificar cuáles prospectos
son malos. No es muy difícil si sólo hay unos cuantos miles, pero
¿qué hace uno cuando hay más de un cuarto de millón?”.
Ryan continúa, “Como usamos estos datos con frecuencia para
enviar muchos correos, es muy importante para nosotros asegurar
que los nombres y direcciones en ese archivo tengan la mayor exac-
titud posible. Por ejemplo, deben conformarse a los estándares
postales y no debe haber duplicados.”
“Para lograr esto utilizamos una técnica llamada higiene de
datos. ¿Qué tal suena ese término especializado? Por lo general
logramos la higiene de los datos mediante software especializado,
el cual se utiliza para determinar la validez de una dirección. Este
software relaciona la dirección de la base de datos con su propia
base de datos interna de calles y rangos de números válidos en una
ciudad o código postal específico”.
Ryan prosigue: “Uno de los otros retos de datos a los que se
enfrentan los que trabajan en marketing es la eliminación de regis-
tros duplicados en la base de datos de marketing. Hay dos tipos de
duplicados a buscar: duplicados internos, que consisten en la exis-
tencia de varios registros del mismo cliente o prospecto, y los du-
plicados externos, que representan nuestra incapacidad de eliminar
clientes de nuestros datos de prospectos”.
“Los duplicados internos crean problemas en los informes e
incrementan los costos del servicio de correo. Los duplicados exter-
nos son incluso peores: son tanto costosos como vergonzosos”.
Ryan explica: “Una de las cosas más vergonzosas para un represen-
tante de ventas es realizar una llamada a un prospecto sólo para
descubrir que ya es nuestro cliente. Por lo general, el cliente se
queda con la sensación de que es sólo un número en una de nuestras
computadoras. Además de la mala impresión, desperdicia el valioso
tiempo y los recursos”.
Describa en dos párrafos algunas técnicas que podría usar
Ryan para ayudar a identificar los duplicados internos y externos en
la base de datos de marketing de su empresa. Describa cómo crearía
una base de datos de marketing para minimizar los duplicados (use
un párrafo). ¿Hay métodos operacionales que podrían reducir este
problema? Haga una lista de ellos. ¿Quién más en la organización
podría ayudar con este proceso? Proporcione una lista breve. Reco-
miende en un párrafo los métodos para Chandler y los demás miem-
bros de su equipo de análisis de sistemas que se puedan usar para
ayudar a reclutar y asegurar la asistencia de otros miembros rele-
vantes de la organización.www.xlibros.com

432 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
postal como una forma de determinar cuál podría ser el ingreso de una familia (suponiendo que ésta debe generar
suficiente ingreso como para poder vivir en el prestigioso código postal 90210 de Beverly Hills o en algún otro
vecindario acomodado). Era una manera (imperfecta, desde luego) para limitar el número de catálogos enviados.
La minería de datos lleva este concepto un paso más allá. Si suponemos que el comportamiento anterior es
un buen vaticinador de las compras futuras, se recopila una gran cantidad de datos sobre una persona específica
a partir de las compras con su tarjeta de crédito. La empresa puede identificar en qué tiendas compramos, qué
hemos comprado y cuánto pagamos por un artículo, además de saber cuándo y con qué frecuencia viajamos. Los
datos también se introducen, almacenan y utilizan para una variedad de propósitos cuando llenamos las garan-
tías, solicitamos una licencia de conductor, respondemos a una oferta gratuita o solicitamos una tarjeta de mem-
bresía en una tienda de renta de videos. Lo que es más: las empresas comparten estos datos y a menudo hacen
dinero al venderlos a terceros.
American Express ha sido líder en minería de datos para fines de marketing. American Express le envía
cupones de descuento para nuevas tiendas o entretenimiento cuando le envía la factura de su tarjeta de crédito,
habiendo determinado que usted compró en tiendas similares o asistió a eventos similares. General Motors ofrece
una tarjeta MasterCard que permite a los clientes acumular puntos de bonificación para la compra de un nuevo
automóvil, y después envía información sobre los nuevos vehículos en el momento en que sería más probable
que el consumidor esté interesado en comprar un auto nuevo.
Sin embargo, la metodología de minería de datos también presenta sus problemas. En primer lugar, los
costos pueden ser demasiado altos como para poder justificar la minería de datos, algo que tal vez se descubra
sólo hasta después de haber acumulado enormes costos de preparación. En segundo lugar, la minería de datos
tiene que estar coordinada de manera que varios departamentos o subsidiarias no traten de contactar al cliente al
mismo tiempo. Además, los clientes tal vez piensen que se ha invadido su privacidad y resientan las ofertas que
reciben. Por último, los clientes podrían pensar que los perfiles creados únicamente con base en sus compras con
tarjeta de crédito presentan una imagen bastante distorsionada de quiénes son en realidad.
Los analistas deben asumir responsabilidad en cuanto a los aspectos éticos de cualquier proyecto de minería
de datos propuesto. Hay que considerar y averiguar, junto con el cliente, todos los detalles sobre el periodo que
se mantendrá el material de los perfiles, la confidencialidad del mismo, las medidas de protección de la priva-
cidad incluidas y los usos que se le darán. Las oportunidades de abuso son evidentes, por lo que debemos estar
protegidos. Para los consumidores, la minería de datos es sólo otra tecnología más que se les impone, y si ellos
no desean que pase esto, los esfuerzos de minería de datos fracasarán.
RESUMEN
Una decisión importante en el diseño de un sistema de infor-
mación es la forma en que se almacenan los datos. Hay dos
metodologías para ello: la primera consiste en almacenarlos en
archivos individuales, usando un archivo para cada aplicación;
la segunda, en desarrollar una base de datos que puedan com-
partir muchos usuarios para varias aplicaciones, a medida que
surja la necesidad.
Para comprender el almacenamiento de los datos hay que
captar tres ámbitos: realidad, datos y metadatos. Una entidad es
un objeto o evento por el que estamos dispuestos a recolectar y
almacenar datos. Los atributos son las características reales de
estas entidades. Los elementos de datos pueden tener valores y
se pueden organizar en registros a los que se puede acceder me-
diante una clave. Los metadatos describen a los datos y pueden
contener restricciones sobre el valor de un elemento de datos
(por ejemplo, que sea sólo numérico).
Algunos ejemplos de archivos convencionales son los ar-
chivos maestros, los archivos de tablas, los archivos de transac-
ciones, los archivos de trabajo y los archivos de informes. Por
lo general, las bases de datos se construyen con una estructura
relacional. Sin embargo, los sistemas heredados pueden tener
estructuras jerárquicas o de redes.
La normalización es el proceso que toma las vistas de
usuario y las transforma en estructuras menos complejas co-
nocidas como relaciones normalizadas. Hay tres pasos en el
proceso de normalización. En primer lugar se eliminan todos
los grupos repetitivos. En segundo lugar se eliminan todas las
dependencias parciales. Por último se quitan las dependencias
transitivas. Una vez que se completan estos tres pasos, el re-
sultado es la creación de numerosas relaciones que están en la
tercera forma normal (3NF).
Podemos usar el diagrama de entidad-relación para de-
terminar las claves requeridas para un registro o una relación
de una base de datos. Los tres lineamientos a seguir al diseñar
tablas maestras o relaciones de bases de datos son: 1) cada en-
tidad de datos separada debe crear una tabla maestra (no com-
binar dos entidades distintas dentro de una tabla); 2) un campo
de datos específico debe existir en sólo una tabla maestra; y 3) cada
tabla maestra o relación de base de datos debe tener programas
para crear (C), leer (R), actualizar (U) y eliminar (E).
El proceso de recuperar datos puede involucrar hasta
ocho pasos: 1) seleccionar una relación, 2) unir dos relaciones,
3) proyectar (seleccionar) las columnas, 4) seleccionar las filas
relevantes, 5) derivar nuevos atributos, 6) ordenar o indexar fi-
las, 7) calcular totales y medidas de desempeño, y finalmente
8) presentar los resultados al usuario.
La desnormalización es un proceso que toma el modelo de
datos lógico y lo transforma en un modelo físico que sea efi-
ciente para las tareas más necesarias. Los almacenes corporativos
de datos difieren de las bases de datos tradicionales en muchos
aspectos; uno de ellos es que almacenan datos desnormalizados,
los cuales están organizados en base a temas. Los almacenes cor-www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 433
porativos de datos permiten un fácil acceso mediante el software
de minería de datos también conocido como software, el cual
busca patrones e identifica las relaciones que no pueden imagi-
nar los humanos encargados de tomar decisiones.
La minería de datos involucra el uso de una base de da-
tos para una focalización más selectiva de los clientes. Supo-
niendo que el comportamiento anterior es un buen vaticinador
de las compras futuras, las empresas recopilan datos sobre una
persona a partir de las compras con su tarjeta de crédito, las
solicitudes de licencia de conductor, las tarjetas de garantías,
etcétera. La minería de datos puede ser poderosa, pero también
puede ser costosa y debe estar coordinada. Además, puede in-
fringir la privacidad del consumidor o incluso los derechos ci-
viles de una persona.
E X P E R I E N C I A D E H Y P E R C A S E ® 1 3
“ Escuché muchas cosas buenas sobre su equipo de las personas
en Sistemas administrativos. Incluso se ganaron un elogio bien
merecido de Tom Ketcham, a quien no es muy fácil complacer en
estos días. Hasta él está viendo algunas posibilidades. Creo que
hasta ahora han logrado mantenernos unidos... a menos que nos
vayamos en distintas direcciones otra vez. Sólo estoy bromeando.
Les dije que pensaran acerca de si somos una familia, un zoológico
o una zona de guerra. Ahora es el momento de empezar a diseñar
sistemas que se adapten a nosotros. Ya ha estado usted aquí el
tiempo suficiente como para poder formarse esas opiniones. Espero
que sean favorables. Creo que nuestra famosa hospitalidad sureña y
sentido del humor notablemente británico deberían ayudar a in-
fluenciarlo, ¿o no? Estuve tan ocupado tratando de persuadirlo de
que valemos la pena el esfuerzo que olvidé decirle: Tom y Snowden
han acordado pensar en cambiar a una base de datos de algún tipo.
¿Podría tener esto listo en las próximas dos semanas? Tom está en
una conferencia en Minneapolis, pero cuando regrese sería exce-
lente que usted tuviera algunas ideas al respecto para que Snowden
y Tom discutan sobre ellas. Siga perseverando”.
Preguntas de HYPERCASE
1. Suponga que los miembros de su equipo han usado el Informe
de características de los clientes de la Unidad de capacitación
(Training Unit Client Characteristics Report) para diseñar una
tabla de base de datos que almacene la información contenida
en este informe, con el siguiente resultado:
2. Aplique la normalización a la tabla que su equipo desarrolló
para eliminar los grupos repetitivos. Muestre sus resultados.
3. Elimine las dependencias transitivas de su tabla y muestre la
tabla de datos resultante.
PALABRAS CLAVE Y FRASES
administrador de base de datos
almacén de datos
almacenamiento de datos
anomalía de actualización
anomalía de eliminación
archivo convencional
archivo de informes
archivo de tablas
archivo de trabajo
archivo de transacciones
archivo maestro
atributo
base de datos
caracteres especiales
clave concatenada
clave primaria
clave secundaria
CRUD (crear, leer, actualizar y eliminar)
datos limpios
dependencias parciales
dependencias transitivas
desnormalización
Nombre de tabla: TABLA CLIENTES
Nombre de columna Descripción
ID CLIENTE
(clave primaria)
Nemónico inventado por los
usuarios, como STHSP para State
Hospital
NOMBRE CLIENTE El nombre actual completo del
cliente
DIRECCION La dirección del cliente
CONTACTO El nombre de la persona de
contacto
NUMERO TELEFONICO El número telefónico de la persona
de contacto
CLASE El tipo de institución (Hospital de
administración de veteranos,
clínica, otro)
TAMANIO-PERSONAL Tamaño del personal del cliente
(número)
NIVEL CAPACITACION Mínimo nivel de experiencia
requerido del personal (según lo
definido por la clase)
CTD-EQUIP El número de equipos médicos que
tiene el cliente
TIPO EQUIP El tipo de equipos médicos (por
ejemplo, rayos X, IRM, TAC)
MODELO-ANIO EQUIP El modelo y año de cada equipo
médicowww.xlibros.com

434 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
diagrama de burbuja
diagrama de modelo de datos
diagrama entidad-relación (E-R)
elemento de datos
elemento de información
entidad
estructura de datos de red
estructura de datos jerárquica
estructura de datos relacional
grupo repetido
identificador de objetos (OID)
integridad de dominio
integridad referencial
minería de datos
normalización
primera forma normal (1NF)
procesamiento analítico en línea (OLAP)
realidad, datos y metadatos
recuperación
recuperación de información
registro
relación
relación sin normalizar
restricción de integridad de entidad
segunda forma normal (2NF)
siftware
sistema de administración de bases de datos (DBMS)
subtipo de entidad
tercera forma normal (3NF)
vista física
vista lógica
PREGUNTAS DE REPASO
1. ¿Cuáles son las ventajas de organizar el almacenamiento de datos como archivos separados?
2. ¿Cuáles son las ventajas de organizar el almacenamiento de datos mediante una metodología de base de datos?
3. ¿Cuáles son las medidas de efectividad del diseño de bases de datos?
4. Mencione algunos ejemplos de entidades y sus atributos.
5. ¿Cuál es la diferencia entre una clave primaria y un identificador de objetos?
6. Defina el término metadatos. ¿Cuál es el propósito de los metadatos?
7. Mencione los tipos de archivos convencionales de uso común. ¿Cuáles de éstos son archivos temporales?
8. Mencione los tres tipos principales de organización de bases de datos.
9. Defina el término normalización.
10. ¿Qué se elimina cuando una relación se convierte a la primera forma normal?
11. ¿Qué se elimina cuando una relación se convierte de 1NF a 2NF?
12. ¿Qué se elimina cuando una relación se convierte de 2NF a 3NF?
13. Mencione las tres restricciones de entidad. Describa en un enunciado el significado de cada restricción de entidad.
14. Describa las cuatro anomalías que pueden ocurrir al crear tablas de bases de datos.
15. Mencione los ocho pasos para recuperar, preordenar y presentar los datos.
16. ¿Qué hace la unión? ¿Qué es la proyección? ¿Qué es la selección?
17. Defina desnormalización.
18. Explique las diferencias entre bases de datos tradicionales y almacenes corporativos de datos.
19. Defina qué hace el software cuando se utiliza en minería de datos.
PROBLEMAS
1. Dado el siguiente archivo de arrendatarios:
a. Muestre un ejemplo de proyección.
b. Muestre un ejemplo de selección.
c. Muestre dos ejemplos de cómo ordenar filas.
d. Muestre un ejemplo de cómo calcular los totales.
Número de
registro
Apellido paterno Número de
apartamento
Renta Expiración del
arrendamiento
41 Warkentin 102 550 4/30
42 Buffington 204 600 4/30
43 Schuldt 103 550 4/30
44 Tang 209 600 5/31
45 Cho 203 550 5/31
46 Yoo 203 550 6/30
47 Pyle 101 500 6/30www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 435
2. El siguiente es un ejemplo de una boleta de calificaciones para dos estudiantes en la University of Southern New Jersey:
Dibuje un diagrama de modelo de datos con asociaciones para la vista de usuario.
3. Convierta la vista de usuario del problema 2 a una relación 3NF. Muestre cada paso del proceso.
4. ¿Qué problema podría surgir al utilizar el número de curso como clave primaria para los datos en el problema 2?
(Sugerencia: Piense sobre lo que ocurriría si cambia el Nombre del departamento [no se muestra en los datos]).
5. Dibuje un diagrama de entidad-relación para la siguiente situación: muchos estudiantes practican muchos deportes. Una
persona denominada entrenador en jefe asume el papel de entrenador en todos estos deportes. Cada una de las entidades
tiene un número y un nombre (haga las suposiciones necesarias para completar un diagrama razonable. Haga una lista de
sus suposiciones).
6. El diagrama de entidad-relación que dibujó en el problema 5 representa las entidades de datos necesarias para
implementar un sistema para rastrear a los estudiantes y los deportes que practican. Haga una lista de las tablas necesarias
para implementar el sistema, junto con las claves primarias, secundarias y externas que se requieren para vincular las
tablas.
7. Dibuje un diagrama de entidad-relación para la siguiente situación: una panadería comercial fabrica muchos productos:
panes, postres, pasteles especiales y muchos otros productos horneados. La panadería compara a varios distribuidores los
ingredientes como harina, especias y leche. Algunas veces compran un ingrediente a un solo distribuidor y otras veces lo
compran a varios. La panadería tiene clientes comerciales, como escuelas y restaurantes, que hacen pedidos de productos
horneados con regularidad. Cada producto horneado tiene un especialista que supervisa la organización de la operación
de la panadería e inspecciona el producto terminado.
8. Haga una lista de las tablas y claves que se necesitan para implementar el sistema de la panadería comercial.
9. Dibuje un diagrama E-R para el sistema de pedidos de la figura 13.24.
10. Dibuje un diagrama de flujo de datos para colocar un pedido. Base su diagrama de flujo de datos en el diagrama E-R.
11. Cree un diagrama de entidad-relación para un paquete de software de genealogía llamado “PeopleTree” con el que se
puede llevar un registro de los ancestros. Suponga que cada persona estará en una tabla Persona y que una persona puede
tener padres (un padre y una madre) biológicos y padres (un padre y una madre) adoptivos. Las madres y padres se
deben almacenar en la tabla Persona también. Cada persona sólo debe tener un lugar de nacimiento, el cual se debe
almacenar en la tabla Persona. Muchas personas pueden nacer en el mismo lugar.
12. Defina la clave primaria utilizada para las tablas Persona y Lugar.
USNJ - Boleta de calificaciones – Primavera – Semestre 2010
Nombre: I. M. Smarte Especialidad: MIS
Estudiante: 053-06929-24 Estado: Avanzado
Número de curso Título del curso Profesor
Departamento
del profesor Calificación
MIS 403 Análisis de sistemas Diggs, T. MIS A
MIS 411 Fundamentos conceptuales Barre, G. MIS A
MIS 420 Factores humanos en SI Barre, G. MIS B
CIS 412 Diseño de bases de datos Menzel, I. CIS A
DESC 353 Modelos de administración Murney, J. MIS A
USNJ - Boleta de calificaciones – Primavera – Semestre 2010
Nombre: E. Z. Grayed
Estudiante: 472-6124-59
Especialidad: MIS
Estado: Avanzado
Número de curso Título del curso Profesor
Departamento del
profesor Calificación
MIS 403 Análisis de sistemas Diggs, T. MIS B
MIS 411 Fundamentos conceptuales Barre, G. MIS Awww.xlibros.com

436 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
13. GaiaOrganix es una cooperativa de mayoreo de comida orgánica que vincula a productores y consumidores.
GaiaOrganix negocia las compras que las tiendas de abarrotes y demás tiendas relacionadas hacen a los granjeros que
cultivan una variedad de cosechas, como frutas, vegetales y granos. Cada granjero puede producir varias cosechas y
varios granjeros pueden producir una cosecha. Para proveer el nivel más alto de productos frescos, éstos se envían
directamente de la granja a la tienda. Cada tienda puede comprar de muchas granjas y cada granja puede vender a
muchas tiendas. Dibuje un diagrama de entidad-relación en la tercera forma normal que muestre la relación entre el
productor (granjas) y el vendedor (tiendas).
14. ArticleIndex.com es una empresa que produce índices de artículos de revistas y periódicos para una disciplina específica.
Un usuario Web debe tener la capacidad de introducir el tema o los autores de un artículo para recibir una lista detallada
de todos los artículos y periódicos en los que se encontró el tema. Cada artículo puede tener muchos autores y cada autor
puede escribir muchos artículos. Un artículo puede existir sólo en un periódico, pero cada periódico por lo general
contiene muchos artículos. Cada artículo puede tener muchos temas y cada tema puede estar en muchos artículos. Dibuje
un diagrama de entidad-relación en la tercera forma normal para los artículos, autores, periódicos y temas.
15. Identifique las claves primarias y externas para el diagrama de entidad-relación creado en el problema 14.
PROYECTO EN GRUPO
1. Gregg Baker compró boletos para dos conciertos a través de la Web. Sus pedidos se procesaron, las ubicaciones exactas
se asignaron y los boletos se enviaron por separado. Uno de los conjuntos de boletos se perdió en el correo. Cuando
llamó al número de servicio no recordó la fecha ni los números de los asientos, pero la agencia pudo localizar sus
boletos con rapidez debido a que desnormalizó la relación. Describa el sistema de pedidos de boletos mediante un
listado de los elementos de datos que se mantienen en el formulario de pedido y el formulario de envío. ¿Qué
información proporcionó Gregg a la agencia de boletos para recuperar la información?
BIBLIOGRAFÍA SELECCIONADA
Agrawal, R., A. Ailamaki, P. A. Bernstein, E. A. Brewer, M. J. Carey, S. Chaudhuri, et al. “The Claremont Report on Database
Research”. Communications of the ACM, Vol. 52, Núm. 6, 2009, pp. 56-65.
Avison, D. E. Information Systems Development: A Database Approach, 2ª. Edición. Londres: Blackwell Scientific, 1992.
Codd, E. F. “A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM, Vol. 13, Núm. 6, 1970,
pp. 377-387.
Deitel, H. M., P. J. Deitel y T. R. Nieto. E-Business and E-Commerce: How to Program. Upper Saddle River, NJ: Prentice Hall,
2001.
Gane, C. y T. Sarson. Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, NJ: Prentice Hall, 1979.
Gray, P. “Data Warehousing: Three Major Applications and Their Significance”. En Emerging Information Technologies, Im-
proving Decision, Cooperation, and Infrastructure. Editado por K. E. Kendall, Thousand Oaks, CA: Sage Publications,
1999.
Hoffer, J., A. Prescott y H. Topi. Modern Database Management, 9ª. Edición. Upper Saddle River, NJ: Prentice Hall, 2009.
Sanders, G. L. Data Modeling. Nueva York: International Thomson Publishing, 1995.
Shin, S. K. y G. L. Sanders. “Denormalization Strategies for Data Retrieval from Data Warehouses”. Decision Support Systems,
Vol. 42, Núm, 1, 2006, pp. 267-282.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 437
Contiene
Instalada en
Numero inventario hardware +
Nombre marca +
Modelo +
Numero serie +
Fecha compra +
Costo compra +
Costo reemplazo +
Tamanio memoria +
Capacidad disco duro +
Capacidad segundo disco duro +
Unidad optica +
Sistema operativo +
Intervalo actualizacion +
Duracion garantia +
Descripcion campus +
Ubicacion sala +
{Numero inventario software}
Numero inventario software +
Titulo +
Nombre sistema operativo +
Numero version +
Editorial +
Descripcion categoria software +
Marca computadora +
Modelo computadora +
Memoria requerida +
Licencia sitio +
Numero de copias +
Apellido paterno experto +
Primer nombre experto +
Telefono oficina
SoftwareComputadora
FIGURA E13.1
Diagrama de entidad-relación sin
normalizar para el sistema
computarizado. La relación de
muchos a muchos se tendrá que
definir como una entidad
asociativa.
E P I S O D I O 1 3
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
De vuelta a los fundamentos de datos
Después de realizar numerosas entrevistas, prototipos, diagramas de flujo de datos, entradas en el diccionario de datos y
diagramas de UML, Anna y Chip empiezan a trabajar en el modelo de entidad-relación. “Yo seré responsable de crear las
relaciones de las tablas de Microsoft Access”, afirma Anna. Chip se ofrece a completar un diagrama de entidad-relación.
“Cuando terminemos, vamos a comparar los dos diagramas en cuanto a precisión y consistencia”, sugiere Anna, y así lo
hacen.
La figura E13.1 muestra el diagrama de entidad-relación para el sistema de inventario de computadoras. Visible Analyst
llama a cada uno de los rectángulos una entidad. Cada entidad representa una tabla de base de datos de información almacenada
en el sistema, correspondiente a un almacén de datos en el diagrama de flujo de datos o a una clase de entidad en un diagrama
de secuencia o de clases. Cada uno de los rectángulos en forma de diamante representa una entidad asociativa que representa
una relación entre las entidades de datos. Un rectángulo con un óvalo en su interior representa a una entidad asociativa que no
puede existir sin la entidad conectora. Por lo general éstos son elementos repetitivos. Microsoft Visio usa rectángulos para re-
presentar tanto una entidad asociativa como una entidad atributiva.
“Terminé de crear el diagrama de entidad-relación, empezando con las porciones más simples del sistema”, Chip dice a
Anna. “Las primeras entidades de datos creadas son SOFTWARE y COMPUTADORA. La relación es que el software se
instala en la computadora. Después determiné la cardinalidad de la relación. Como un paquete de software se puede instalar en
muchas computadoras, esta relación es de uno a muchos. Cada computadora también puede tener varios paquetes de software
instalados en ella, por lo que también provee una relación de uno a muchos. Como hay una relación de uno a muchos para cada
una de las entidades de datos, la relación completa entre ellas se vuelve de muchos a muchos”.
Chip continúa y dice: “Esta primera vista está lejos de ser normalizada. Observa que NUMERO INVENTARIO SOFT-
WARE es un elemento repetitivo en la entidad HARDWARE. Voy a tener que crear varias entidades para cada uno de ellos”.
Poco después, Chip revisa su trabajo con Anna. Se quitó el NUMERO INVENTARIO SOFTWARE y se colocó en una entidad
relacional. Consulte el diagrama de entidad-relación que se muestra en la figura E13.2. “Esto coloca a los datos en la primera
forma normal”, comenta Chip. “Además, no hay elementos que dependan sólo de una parte de la clave, por lo que los datos
también se encuentran en la segunda forma normal. Sin embargo, hay elementos que no forman parte de la entidad que se re-
presenta en el diagrama y habrá que eliminarlos. Por ejemplo, da un vistazo a SISTEMA OPERATIVO y a EDIFICIO CAM-
PUS. Estos elementos no son parte del hardware de computadora, pero están instalados en la computadora o la computadora
está instalada en una sala del campus. Deben tener su propia entidad. Esto facilita el proceso de cambiar la versión de un sistema
operativo. En vez de tener que cambiar la versión del sistema operativo en muchos de los registros de COMPUTADORA, ten-
dríamos que cambiarlo sólo una vez”.
Anna asiente y comenta: “Es realmente una buena valoración de la situación. Facilitará la implementación de las tablas de
Microsoft Access”.www.xlibros.com

438 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Edificio campus
Computadora
Sistema operativo
Codigo campus +
Descripcion campus
Codigo sistema operativo +
Nombre sistema operativo
Numero inventario hardware +
Nombre marca +
Modelo +
Intervalo actualizacion +
Duracion garantia +
Codigo campus
tiene
computadoras
dentro de
están
localizadas
en
tiene
un
provee
soluciones
para
obtiene
ayuda
de
Numero empleado +
Apellido paterno experto +
Primer nombre experto +
Telefono oficina +
Direccion email +
Codigo departamento +
Enseña curso
Numero inventario software +
Titulo +
Nombre sistema operativo +
Numero versión +
Editorial +
Codigo categoría software +
Numero empleado
pertenece
a
descrito
por
se relaciona con
puede tener
tiene
se relaciona con
Numero inventario hardware +
Numero inventario software
Codigo categoria software +
Descripcion categoria software
Experto software
Software
Categoria software
Hardware
Software
FIGURA E13.3
Diagrama de entidad-relación final para el sistema computarizado.
Chip continúa trabajando en el diagrama de entidad-relación. Después de unas cuantas horas exclama: “Creo que está listo.
¿Podrías dar un vistazo a la versión final?”. En la figura 13.3 se muestra la versión final. Se describieron todas las entidades y
relaciones en el repositorio.
Anna revisa la versión final y exclama, “¡Se ve excelente! Tuviste razón en mover SISTEMA OPERATIVO y EDIFICIO
CAMPUS a sus propias entidades. Buena idea, ya que el edificio no es parte de la computadora. Además, en definitiva el EX-
PERTO DE SOFTWARE no es parte de la entidad SOFTWARE. ¿Qué hay sobre CATEGORIA SOFTWARE?”.
“Moví la CATEGORIA SOFTWARE a su propia entidad para ahorrar espacio en los archivos maestros cuando se constru-
yan”, responde Chip. “En realidad es una tabla de códigos y facilita el proceso de cambiar la categoría sin tener que cambiar
todos los registros de software. Además vamos a almacenar un pequeño código en vez de una descripción extensa en cada re-
gistro de software. ¿Por qué no revisas dos veces las diversas claves en el diagrama? Cada entidad relacionada en el extremo de
muchos debería tener una clave externa que coincida con la clave primaria de la entidad en el extremo de uno”.
Anna examina el diagrama por un instante y comenta, “Se ve bien, en mi opinión. Tal vez debamos definir las entradas en
el repositorio”.
“Mira esta entrada en el repositorio”. Chip abre el diagrama de entidad-relación (figura E13.4) y hace doble clic en la
entidad COMPUTERS (COMPUTADORAS) para mostrar su entrada en el repositorio. Se definieron la clave primaria (la no-
tación [pk] de Microsoft Visio y Visible Analyst frente al elemento NUMERO INVENTARIO HARDWARE [HARDWARE
puede tener
tiene
Numero inventario hardware +
Numero inventario software
Numero inventario hardware +
Nombre marca +
Modelo +
Numero serie +
Fecha compra +
Costo compra +
Costo reemplazo +
Tamanio memoria +
Capacidad disco duro +
Capacidad segundo disco duro +
Unidad optica +
Sistema operativo +
Intervalo actualizacion +
Duracion garantia +
Descripcion campus +
Ubicacion sala +
Numero inventario software +
Titulo +
Nombre sistema operativo +
Numero version +
Editorial +
Descripcion categoria software +
Marca computadora +
Modelo computadora +
Memoria requerida +
Licencia sitio +
Numero de copias +
Apellido paterno experto +
Primer nombre experto +
Telefono oficina
Computadora Software
Hardware
Software
FIGURA E13.2
El diagrama de entidad-relación
del sistema computarizado en
primera forma normal.www.xlibros.com

CAPÍTULO 13 • DISEÑO DE BASES DE DATOS 439
FIGURA E13.4
El diagrama de entidad-relación
normalizado de la CPU se muestra
en Microsoft Visio con la
definición del repositorio para
Software.
FIGURA E13.5
Un diagrama de RELACIONES
de Microsoft Access. Observe los
símbolos de infinito que
representan el extremo de muchos
de una relación.
INVENTORY NUMBER] en el área de composición), las claves externas (FK1, FK2 y así en lo sucesivo) y varias claves alter-
nas ([Ak1],[Ak2] y [Ak3]). Después de invertir tiempo en examinar el diagrama, así como las entradas en el repositorio y los
informes de análisis, tanto Anna como Chip quedan satisfechos de que las relaciones entre los datos estén representadas en
forma precisa. A continuación deciden cómo diseñar la base de datos a partir de los diagramas.
Primero analizan la relación HARDWARE/SOFTWARE. Como hay una relación de muchos a muchos entre estas dos
entidades de datos, se puede implementar mediante el uso de tres tablas de base de datos:
1. Una tabla MAESTRA DE HARDWARE (HARDWARE MASTER).
2. Una tabla MAESTRA DE SOFTWARE (SOFTWARE MASTER).
3. Una tabla RELACION HARDWARE/SOFTWARE (HARDWARE/SOFTWARE RELATIONSHIP), que debe contener los
campos clave de las tablas maestras HARDWARE y SOFTWARE para todo el software instalado en todas las máquinas. También
podría funcionar una clave de primaria de autosecuencia, siempre y cuando se incluyan las claves externas en la tabla.
“Creo que es mi turno de trabajar en las relaciones”, dice Anna mientras saca una copia del diagrama de entidad-relación. Voy
a modificar las tablas de Microsoft Access de las sesiones de los prototipos”.
Para empezar, Anna establece las claves primarias para cada una de las tablas. Cuando éstas se encuentran en su forma
final, crea las relaciones entre ellas. En la figura E13.5 se muestra el diagrama de relaciones de Microsoft Access. Los rectán-www.xlibros.com

440 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
gulos en el diagrama representan las tablas de la base de datos y corresponden a los diversos tipos de entidades que se encuen-
tran en el diagrama de entidad-relación. Tenga en cuenta que la cardinalidad se representa mediante “1” y el símbolo de infinito.
Los campos que son claves primarias se listan como el primer campo de cada rectángulo; también se muestran en negrita. Las
claves externas se muestran unidas al otro extremo de la línea de la relación, si la clave externa es visible en el rectángulo de la
tabla. Las claves se arrastran de una tabla a otra para establecer una relación; aparece un cuadro de diálogo para determinar las
propiedades de la relación.
EJERCICIOS
E-1. Use Microsoft Visio o Visible Analyst para ver los diagramas de entidad-relación sin normalizar y en primera forma
normal para el sistema computarizado. Haga doble clic en las entidades para ver la información del repositorio. (En
Microsoft Visio y en Visible Analyst; en Microsoft Visio la entrada del repositorio está en un área en la parte inferior de
la pantalla. Tal vez tenga que arrastrar el borde que separa el diagrama del repositorio hacia arriba. Haga clic en la entrada
Columnas (Columns) que está en el área Categorias (Categories) del lado izquierdo del repositorio para ver los atributos
de entidad). El nombre del diagrama es SISTEMA COMPUTARIZADO – SIN NORMALIZAR (COMPUTER SYS-
TEM – UNNORMALIZED).
E-2. Use Microsoft Visio o Visible Analyst para ver el diagrama de entidad-relación del sistema computarizado. Haga doble
clic en las entidades para ver la información del repositorio (en Microsoft Visio y en Visible Analyst). El nombre del
diagrama es COMPUTADORA (COMPUTER).
E-3. Agregue la entidad DISTRIBUIDOR (VENDOR) al diagrama. El distribuidor garantiza las computadoras; la relación
entre DISTRIBUIDOR y COMPUTADORA es que un VENDEDOR puede garantizar muchas COMPUTADORA(s).
Agregue las claves primarias. Microsoft Visio creará de manera automática las claves externas. En Visible Analyst, se-
leccione Sincronización de claves (Key Synchronization) del menú Repositorio (Repository).
E-4 Agregue la entidad MANTENIMIENTO (MAINTENANCE) al diagrama. Las reparaciones de mantenimiento se reali-
zan en las computadoras; la relación entre MANTENIMIENTO y COMPUTADORA(s) es tal que una COMPUTA-
DORA puede tener muchos registros de MANTENIMIENTO. Use el repositorio para definir NUMERO PEDIDO
MANTENIMIENTO (MAINTENANCE ORDER NUMBER). Establezca este atributo como clave primaria para la en-
tidad MANTENIMIENTO y genere la clave externa.
E-5. Describa la entidad CATEGORIA SOFTWARE (SOFTWARE CATEGORY) en el repositorio. Incluya los elementos que
se encuentran en el diagrama de entidad-relación debajo de CATEGORIA SOFTWARE en el área Composición (Com-
position).
E-6. Describa la entidad MANTENIMIENTO (MAINTENANCE) en el repositorio. Los elementos son los siguientes:
a. NUMERO ORDEN MANTENIMIENTO (MAINTENANCE ORDER NUMBER)
b. NUMERO INVENTARIO HARDWARE (HARDWARE INVENTORY NUMBER)
c. FECHA MANTENIMIENTO (MAINTENANCE DATE).
d. TIPO DE MANTENIMIENTO (TYPE OF MAINTENANCE).
e. COSTO DE MANTENIMIENTO (COST OF MAINTENANCE).
f. MANTENIMIENTO CUBIERTO POR GARANTIA (MAINTENANCE COVERED BY WARRANTY).
E-7. Describa la entidad DISTRIBUIDOR (VENDOR). Los elementos son los siguientes:
a. NUMERO DISTRIBUIDOR (VENDOR NUMBER).
b. NOMBRE DISTRIBUIDOR (VENDOR NAME).
c. CALLE (STREET).
d. CIUDAD (CITY).
e. ESTADO (STATE).
f. CODIGO POSTAL (ZIP CODE).
g. NUMERO TELEFONICO (TELEPHONE NUMBER).
h. FECHA ENVIO ULTIMO PEDIDO (DATE LAST ORDER SENT).
i. MONTO TOTAL COMPRA DISTRIBUIDOR (TOTAL AMOUNT PURCHASED FROM VENDOR).
j. NUMERO TOTAL DE PEDIDOS ENVIADOS AL DISTRIBUIDOR (TOTAL NUMBER OF ORDERS SENT TO
VENDOR).
E-8. Cada computadora puede tener más de un sistema operativo y cada sistema operativo puede estar instalado en más de
una computadora. Agregue una entidad asociativa llamada SISTEMA OPERATIVO COMPUTADORA (COMPUTER
OPERATING SYSTEM) entre COMPUTADORA (COMPUTER) y SISTEMA OPERATIVO (OPERATING SYS-
TEM). Incluya las claves primarias y externas en el repositorio, ya sea en Microsoft Visio o en Visible Analyst.
E-9. Explique en un párrafo la relación entre una clave externa y una clave primaria, y por qué es necesario tenerlas en enti-
dades separadas cuando hay una relación entre las entidades.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.www.xlibros.com

441
C A P Í T U L O 1 4
Interacción
humano-computadora
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender la interacción humano-computadora (HCI).
2. Diseñar gran variedad de interfaces de usuario.
3. Diseñar un diálogo efectivo para la HCI.
4. Comprender la importancia de la retroalimentación del usuario.
5. Asumir las implicaciones de la HCI para diseñar sitios Web de comercio electrónico.
6. Formular consultas que permitan a los usuarios buscar en la Web.
Conforme avanza en el libro, usted va cobrando mayor conciencia sobre la
interacción humano-computadora (HCI) y la importancia que tiene para llevar
a cabo sus tareas como analista de sistemas. En este punto necesita dominar
los conceptos relacionados con la HCI, además de volverse un experto en la
evaluación de los requerimientos humanos de información para incorporar
sus hallazgos a sus diseños. La Unión Europea (UE) y Estados Unidos han ideado lineamientos
específicos de usabilidad; éstos prescriben que los sitios Web y servicios electrónicos sean accesi-
bles tanto para las personas con capacidades normales como para las discapacitadas.
En este capítulo lo pondremos al tanto sobre los detalles relacionados con la HCI y la forma
de trabajar con los usuarios. También le proporcionaremos cierta experiencia en la aplicación de
los conceptos de HCI que usted ha estado aprendiendo para ayudarlo con el diseño de interfaces
humano-computadora, retroalimentación, sitios Web de comercio electrónico y consultas Web.
COMPRENSIÓN DE LA INTERACCIÓN HUMANO-COMPUTADORA
Diseñar para HCI implica “asegurar la funcionalidad y usabilidad del sistema proporcionando un
soporte efectivo a las interacciones con el usuario y posibilitándole una experiencia placentera ”.
Además, “el objetivo primordial es alcanzar efectividad y eficiencia para el usuario tanto empresa-
rial como individual. Para cumplir con estas metas, los gerentes y desarrolladores necesitan cono-
cer a fondo la interacción entre los usuarios, tareas, contextos de tareas, tecnología de información
(TI) y los entornos en los que se utilizan los sistemas” (Carey et al., 2004, p. 358).
Mediante la consideración de las interfaces a la luz de las cuestiones de HCI, y gracias a
nuevas maneras de aplicar los conceptos de diseño estándar a las computadoras bajo un enfoque
HCI, podemos asegurar que nuestros sistemas se centren en el usuario, de manera que permitan
satisfacer tanto las necesidades de éstos como las de la organización. El fundamento de la HCI
consiste en conocer la interacción entre los usuarios, las tareas, los contextos de las tareas, la TI y
los entornos donde se utilizan los sistemas. En el análisis y diseño de sistemas, la principal táctica
de la HCI consiste en, primeramente, obtener retroalimentación constante de los usuarios sobre sus
experiencias con los diseños para los que se crearon prototipos (pantallas, formularios, interfaces,www.xlibros.com

442 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
N a t u r a l e z a
d e l
t r a
b
a
j
o
E
n
t
o
r
n
o
E
s
p
a
c
i
o
d
e
t
r
a
b
a
j
o
Humano
Computadora
Tarea
Ajuste
Desempeño y
bienestar
FIGURA 14.1
El “ajuste” entre humano,
computadora y tarea afecta al
desempeño y al bienestar.
etcétera), para después refinar el diseño con base en los cambios sugeridos y probarlos de nuevo con los usua-
rios, hasta que el diseño sea aceptable y el analista lo considere “congele”.
Cómo el ajuste afecta al desempeño y al bienestar
Comenzaremos nuestra exploración de la HCI con algunas definiciones de uso común en el campo.
AJUSTE Un buen ajuste entre los elementos de HCI del humano, la computadora y la tarea a desarrollar conducen
al desempeño y bienestar, como se muestra en la figura 14.1. Así como es importante que los zapatos nuevos se
ajusten cómodamente al contorno de su pie, que den sustento a la actividad a realizar (como correr) y que estén
fabricados de un material (como la piel) duradero y efectivo en costo, también es importante un ajuste apropiado
entre el usuario, la computadora y la tarea.
Los analistas desean el mejor ajuste para su diseño; aspiran a emplear al personal, de la mejor manera posi-
ble, para diseñar una tarea computarizada que cumpla con un objetivo de la organización. Un mejor ajuste pro-
duce mejor desempeño y mayor bienestar general para el humano involucrado con el sistema.
Por fortuna, la capacidad humana de aprender mejores formas para trabajar también influye en el
ajuste. Nunca trataríamos de correr un maratón con unos zapatos nuevos sin antes “domarlos”. De igual
forma podemos mejorar el ajuste a un nuevo sistema capacitando antes a los usuarios para que aprendan sus
tareas y conozcan sus computadoras a fondo. La capacitación sigue siendo una forma importante de mejorar
el ajuste.
TAREA En los capítulos anteriores aprendió muchos métodos que le ayudan a comprender, documentar y describir
gráficamente las tareas que las personas desempeñan actualmente en la organización. También aprendió sobre los
métodos que le pueden ayudar a diseñar nuevas tareas para ayudar a las personas a cumplir sus objetivos con
los nuevos sistemas que usted va a crear. Como recordará, las tareas pueden ser estructuradas y rutinarias, o
pueden estar mal definidas y sin una estructura aparente. Las tareas complejas que requieren de la interacciónwww.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 443
entre humano, sistema y tarea se respaldan mediante sistemas Web y de comercio electrónico, sistemas ERP y
sistemas inalámbricos dentro y fuera de la organización.
DESEMPEÑO La definición de desempeño en el contexto de la HCI también es clave: se refiere a una combinación
de la eficiencia involucrada al desempeñar una tarea y la calidad del trabajo que ésta produce. Por ejemplo, si
los analistas utilizan software de alto nivel o una herramienta CASE para crear diagramas de flujo de datos en los
que son muy competentes, podríamos predecir que la calidad de los diagramas de flujo de datos producidos será
alta. El desempeño también es eficiente, ya que los analistas utilizan una herramienta automatizada con la que
están familiarizados: pueden trabajar con rapidez y obtener buenos resultados. La tarea se ajusta al objetivo,
que es crear diagramas de flujo de datos de alta calidad para documentar un sistema. La eficiencia de producir
dichos diagramas con una herramienta CASE —que se puede usar después para almacenar, recuperar, comunicar
y modificar los diagramas de UML—, es excelente si se le compara con alternativas como usar una herramienta
de dibujo no relacionada con un diccionario, o con la opción de dibujar los diagramas a mano, dado que ninguna de
ellas ofrece las ventajas mencionadas.
BIENESTAR En este punto podemos presentar el concepto de bienestar: la preocupación por la comodidad,
seguridad y salud de un humano en general; por su buen estado físico y psicológico. ¿Acaso usar una herramienta
CASE para producir diagramas de UML o DFD en una computadora sirve para el bienestar del analista? Sí, ya
que la tarea se ajusta bien al analista, al software, al objetivo y a la computadora, y se parte de que los analistas
trabajan en un entorno en el que están físicamente cómodos, reciben estímulo psicológico para ser creativos y
pueden ser productivos, además de que los colegas y clientes valoran su trabajo, y la organización que los emplea
les paga correctamente.
También importan las actitudes psicológicas (el componente afectivo). Es posible medir cómo se sienten los
usuarios con respecto a sí mismos, sus identidades, su vida laboral y desempeño mediante una evaluación de ac-
titudes. Como analista que asume una perspectiva de HCI, usted se debe concentrar en averiguar cómo influyen
las actitudes de los humanos en lo que sienten sobre la tecnología y sus tareas, además de descubrir si sus actitu-
des dificultan o mejoran su experiencia.
El modelo de aceptación de la tecnología y su relación con la actitud
El modelo de aceptación de la tecnología (TAM) propuesto por Davis en 1989, que posteriormente refinó y
mejoró junto con sus colaboradores, es en esencia una forma en que los analistas pueden organizar lo que
piensan sobre el hecho de que los usuarios acepten y utilicen la tecnología de la información. Se puede utili-
zar para dar forma a la capacitación que se imparte después del desarrollo del sistema, y durante las primeras
etapas del proceso de desarrollo para recopilar las reacciones de los usuarios con respecto a los prototipos.
Modificar los sistemas en las primeras etapas del proceso de desarrollo mejora sus probabilidades de adop-
ción y uso.
Existen muchos componentes teóricos y mucha investigación al respecto de las complejidades del TAM. En
términos prácticos, debe estar consciente de que hay un extenso organismo de investigación sobre la aceptación y
el uso de la tecnología en el campo de los sistemas de información, y que TAM es uno de los temas más popula-
res. El poder del TAM proviene de examinar la utilidad percibida del sistema para incrementar el desempeño de
uno mismo en el trabajo, y de la creencia sobre qué tan fácil será el sistema de usar cuando un usuario se siente
a realizar una tarea. Esto provee dos claves: utilidad percibida y facilidad de uso percibida. Ambas se pueden
usar para comprender cómo pretenden los usuarios interactuar con un sistema propuesto. Algunos investigadores
agregan al modelo una dimensión de actitud explícita que les ayuda a pensar más específicamente sobre los es-
tados psicológicos que influirán para que los usuarios acepten o rechacen el uso de los sistemas de información
que diseñan.
Las actitudes hacia las computadoras incluyen la satisfacción del usuario con la HCI, así como la satis-
facción de los usuarios con el sistema en general; comúnmente, éstas se establecen a través de encuestas es-
peciales de satisfacción del usuario y a menudo se utilizan después de la implementación para estimar el éxito
o fracaso en general de un proyecto de sistemas. Si intenta caracterizar las actitudes hacia las computadoras,
tal vez le sorprenda todas las posibles respuestas humanas expresadas. La mayor parte de la investigación so-
bre la HCI analiza las actitudes de usuario, incluyendo satisfacción, ansiedad, placer y alegría al acceder a la
tecnología.
El modelo de aceptación de la tecnología también recalca la importancia de que los usuarios encuentren útil
al sistema y por ello se sientan motivados a usarlo; dado que ésta es una de las preocupaciones fundamentales de
la HCI, es posible determinar si la tecnología de la información es útil averiguando si el sistema provee soporte
para las tareas individuales de un miembro de la organización. También podemos medir si hay tareas importantes
que el usuario de un nuevo sistema no podía realizar antes de su implementación. Nuestras mediciones también
pueden determinar si el sistema extiende las capacidades de un usuario (por ejemplo, su capacidad para realizar
un análisis de nivel superior con rapidez o una traducción al instante de un informe financiero a otro idioma, conwww.xlibros.com

444 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
todo y conversiones de moneda). Parte del criterio de utilidad en la HCI se puede medir también al establecer
si los usuarios encuentran gratificante usar el sistema, para lo cual podemos realizar entrevistas y observaciones
después de la implementación.
USABILIDAD
La usabilidad es un término que se define de manera distinta dependiendo de la rama de la ciencia que es-
temos investigando. En el caso que nos ocupa, consideraremos a la usabilidad como un medio con que los
diseñadores cuentan para evaluar, tan minuciosamente como sea posible, sus sistemas e interfaces en términos
de las preocupaciones de la HCI. Los estudios sobre la usabilidad (de acuerdo con www.useit.com) se enfocan
en averiguar lo que funciona y lo que no funciona en el mundo. La ISO ha creado estándares de usabilidad
que podemos explorar en www.usabilitynet.org/tools/r_international.htm. Estos estándares abarcan el uso del
producto (efectividad, eficiencia y satisfacción en un contexto de uso específico), la interfaz e interacción
del usuario, el proceso utilizado para desarrollar el producto y la capacidad de una organización de aplicar un
diseño centrado en el usuario.
Nielsen y Mack (1994) y Nielsen, Molich, Snyder y Farrell (2001) publicaron heurísticas de uso (o reglas
prácticas) con base en los miles de pruebas de usabilidad de las interfaces y, más tarde, en las pruebas de los
sitios Web de comercio electrónico. Aquí se incluye la visibilidad del estado del sistema, la coincidencia entre
el sistema y el mundo real, el control y la libertad del usuario, la consistencia y los estándares, la prevención de
errores, la posibilidad de reconectar en vez de recordar, la flexibilidad y la eficiencia de uso, el diseño estético y
minimalista, la ayuda que reconocen los usuarios, el diagnóstico y la recuperación de los errores, además de la
ayuda y la documentación. Probablemente reconozca algunas de ellas, que vimos en los capítulos sobre el diseño
de la entrada y la salida.
La figura 14.2 muestra una encuesta de usabilidad que se administra directamente a los usuarios que han
interactuado personalmente con un prototipo. Pregunta abiertamente sobre ciertas dimensiones ergonómicas y
de usabilidad que son importantes. Otra metodología es la de escribir escenarios de casos de uso para el sistema,
que son útiles para examinar las cuestiones sobre la usabilidad.
Diseño para los estilos cognoscitivos de usuarios individuales
Un punto importante a considerar es que los datos, en especial los que se utilizan para la toma de decisiones, se
pongan a la disposición de diferentes maneras con el fin de que los usuarios con distintas habilidades cognos-
citivas puedan sacar provecho de ellos. Tal vez algunos usuarios prefieran examinar tablas y tomar decisiones,
algunos prefieran gráficas y otros deseen leer texto descriptivo.
También es concebible que la misma persona desee distintos tipos de presentaciones en distintos momentos.
Por ejemplo, suponga que un gerente desea comparar el inventario en distintas tiendas de una región. Una gráfica
podría presentar los datos con mucha efectividad: una de columnas puede usar colores para mostrar cuando una
tienda está cerca de su nivel de reabastecimiento y también puede mostrar la cantidad relativa de existencia al
permitir que el usuario compare visual y directamente la altura de las barras.
Ahora suponga que la misma persona encargada de tomar decisiones desea información sobre una tienda
específica en cierto mes. Podríamos establecer una descripción gráfica para mostrar las tiendas con el inventario
de mayor a menor, mes por mes. Tal vez el usuario prefiera regresar a la tabla que muestra una lista de las tiendas
por orden alfabético, con los meses en orden cronológico. Como puede ver, la misma persona tal vez quiera ver
los mismos datos en formas muy distintas.
TABLAS DINÁMICAS Las tablas dinámicas permiten a los usuarios ordenar datos en una tabla de la manera
que deseen. En la figura 14.3 se muestra un ejemplo de una tabla dinámica que se creó en Microsoft Excel. El
usuario debería tomar un elemento del cuadro desplegable llamado “Listas de campos de tabla dinámica (Pivot
Table Field List)”, como Producto (Product) por ejemplo, arrastrarlo a la plantilla de la tabla y soltarlo en una
de las áreas en blanco. En este ejemplo el usuario arrastra y suelta Producto en el área a la izquierda titulada
“Coloque campos de fila aquí (Drop Column Fields Here)”. Después suelta Ventas (Sales) en el área más grande
que dice “Coloque datos aquí (Drop Row Fields Here)”.
Por último, el usuario toma el elemento Trimestre (Quarter) y lo suelta en el área llamada “Coloque cam-
pos de columna aquí (Drop Column Fields Here)”. El resultado es una tabla que muestra cada uno de los pro-
ductos en orden alfabético, junto con sus ventas para cada uno de los cuatro trimestres de los que tenemos datos,
seguidos del gran total para todo el año. Esta tabla se muestra en la figura 14.4.
Desde luego que el usuario podría haber hecho lo opuesto; es decir, arrastrar el elemento Trimestre a la
columna de la izquierda y Producto al área que dice “Coloque campos de columna aquí”. Sin embargo, esa ope-
ración hubiera producido una tabla con muchas columnas (una para cada producto) y sólo cinco filas (una para
cada trimestre, más una fila para el total). La tabla resultante hubiera sido difícil de leer.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 445
Llene esta encuesta después de que haya interactuado con el prototipo. Circule un número a medida que responde a
cada pregunta. Entregue su encuesta al analista cuando haya terminado. Gracias por su valiosa retroalimentación.
1. ¿Qué tan bien pudo leer la pantalla o formulario?
2. Si se utilizó audio, ¿pudo usted escucharlo?
3. ¿Consideró el sistema seguro de usar?
1
1
1
2
2
2
4
4
4
5
5
5
3
3
3
1
1
1
1
1
2
2
2
2
2
4
4
4
4
4
5
5
5
5
5
3
3
3
3
3
1
1
1
1
1
2
2
2
2
2
4
4
4
4
4
5
5
5
5
5
3
3
3
3
3
1
1
1
1
1
1
1
2
2
2
2
2
2
2
4
4
4
4
4
4
4
5
5
5
5
5
5
5
3
3
3
3
3
3
3
Prototipo que se evalúa ________________ Versión ___________________ Fecha ____/____/______
Encuesta de usabilidad
Factores de la interacción humano-computadora
Cuestiones físicas/de seguridad
4. le ayuda a reducir los errores?
5. le permite recuperarse de un error si comete uno?
6. le ayuda para usarlo con facilidad?
7. le ayuda a recordar cómo usarlo?
8. le facilita aprender a usarlo?
Cuestiones de usabilidad ¿En qué grado el sistema:
9. ¿Era el sistema atractivo?
10. ¿Era agradable el sistema (quería usarlo)?
11. ¿Confía en él como sistema?
12. ¿Fue satisfactorio su uso?
13. ¿Fue agradable su uso?
14. ¿Era el sistema entretenido?
15. ¿Era el sistema divertido de usar?
Atributos de satisfacción y entretenimiento
16. respaldó su tarea o tareas individuales?
17. le ayudó a extender sus capacidades?
18. fue gratificante en cuanto a su uso?
19. le permitió realizar tareas que el otro sistema
no le permitía?
Atributos de utilidad ¿En qué grado el sistema:
Muy
mal
Muy
bienPromedio
FIGURA 14.2
Podemos usar un formulario para encuestar a los usuarios de prototipos sobre
los factores clave ergonómicos y de usabilidad (categorías basadas en Zhang,
Carey, Te’eni y Tremaine, 2005, tabla de cuestiones de la HCI, p. 522).
Es posible obtener muchas tablas con sólo reordenar estas cuatro variables. Si el usuario arrastrara la va-
riable Categoría (Category) al área que dice “Coloque campos de fila aquí (Drop Column Fields Here)”, las
columnas habrían sido categorías de productos en vez de los trimestres, y la tabla resultante hubiera mostrado
con claridad cuáles elementos pertenecen a cada categoría, además de producir los subtotales de cada una. Si se
arrastrara Categoría al área de la parte superior de la plantilla que dice “Coloque campos de página aquí (Drop
Page Fields Here)”, entonces cada categoría tendría su propia tabla en una página separada.
Las tablas dinámicas son útiles debido a que conceden a los usuarios un mayor control sobre las distintas
formas en que pueden ver los datos dentro de una tabla. En la siguiente sección examinaremos este mismo con-
cepto para las gráficas.www.xlibros.com

446 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.3
Una plantilla de tabla dinámica
puede facilitar a los usuarios la
tarea de ver la información en
distintas formas.
FIGURA 14.4
Después de que el usuario arrastra
los elementos Producto (Product),
Trimestre (Quarter) y Ventas
(Sales) a la plantilla, la tabla tiene
esta apariencia.
ANÁLISIS VISUAL DE BASES DE DATOS Se ha innovado en el despliegue visual de datos durante mucho
tiempo, incluso desde el siglo dieciocho. Las barreras contra el uso extendido de pantallas incluían la falta de
imaginación, la incapacidad de dibujar gráficas y diagramas de manera efectiva en costo y la falta de apreciación
de tales pantallas. El consumidor de información debe ser capaz de interpretar la información en el diagrama o, de
lo contrario, éste aportará muy poco valor.
Hay software disponible para permitir al usuario examinar en forma visual una base de datos u hoja de
cálculo. El producto de Tableau Software es un ejemplo (www.tableausoftware.com). Mediante el uso de una
metodología similar a las tablas dinámicas que vimos en Microsoft Excel, Tableau permite al usuario arrastrar y
soltar variables en una fila o columna para que aparezcan en una gráfica. En la figura 14.5, los elementos Región
(Region) y Dia (Weekday) se designaron como columnas y SUMA (Total de ventas) [SALES(Sales Total)] sewww.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 447
designó como fila. Después se graficó cada Categoría de producto (Product Category) [con “muebles (furni-
ture)” en azul, “artículos de oficina (office supplies)” en naranja y “tecnología (technology)” en verde].
La gráfica demuestra que las ventas de tecnología fueron mayores que en las demás categorías, pero en espe-
cial, las ventas de tecnología fueron mucho mayores que las ventas de muebles o artículos de oficina en la región
Este (East). El usuario pudo ver esto con facilidad debido a que la Región (Region) se destacó como uno de los
separadores al arrastrar este elemento al área como una columna.
Tableau es un paquete de software bien diseñado, ya que va mucho más allá que otras aplicaciones en cuanto
a extender las capacidades del usuario para que realice sus tareas por medio de las técnicas de tablas dinámicas.
Los desarrolladores también descubrieron que los usuarios podrían querer agrupar los datos en lo que conside-
ren un grupo significativo. Así los usuarios pueden continuar el análisis al examinar uno de los grupos con más
detalle.
La figura 14.6 examina la SUMA (Ganancia bruta) [SUM(Gross Profit)] de cada Categoría de producto
de nuestro ejemplo. Esta gráfica usa colores para indicar una ganancia (verde) o una pérdida (rojo). De hecho, la
intensidad del color indica la cantidad de ganancia o pérdida.
FIGURA 14.5
Esta tabla, que muestra las ventas
diarias por categoría y por región,
se produjo mediante el uso de
Tableau.
Fuente: Cortesía de
www.tableausoftware.com.
FIGURA 14.6
Los productos que generan
pérdidas se resaltan en color rojo
brillante en este diagrama de
dispersión, creado mediante el uso
de Tableau.
Fuente: Cortesía de
www.tableausoftware.com.www.xlibros.com

448 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
FIGURA 14.7
Cuando se pueden mostrar
distintos gráficas o tablas en la
misma página, ésta se asemeja a
un tablero de control.
Fuente: Cortesía de
www.tableausoftware.com.
Podemos usar esta gráfica para explorar la situación con más detalle si seleccionamos los tres grupos de círcu-
los de color rojo brillante, los aislamos y después vemos los datos para esas observaciones. Los usuarios pueden
examinar gráficas o simplemente ver las observaciones en una tabla. Una vez más, tienen el control sobre la
forma en que se presenta la información y por ende controlan su tarea para el mejor ajuste cognoscitivo.
En la figura 14.7 se presenta otro ejemplo de Tableau, donde se muestra que este software también puede
crear un tablero de control (vimos el concepto en el capítulo 11). Aquí se muestran una tabla, un diagrama de
dispersión y una gráfica de columnas en la misma página. Las herramientas de análisis visual de este tipo brin-
dan apoyo al pensamiento visual y extienden las capacidades cognoscitivas del usuario para ello. Una pantalla
visual apropiada incrementará la probabilidad de tomar una decisión apropiada.
Consideraciones físicas en el diseño de la HCI
En los capítulos 11, 12 y 13 aprendió los fundamentos para el sólido diseño de pantallas, formularios, sitios
Web y bases de datos. Se incluyó el uso especial de las fuentes, el color y el diseño de la distribución para
comunicarse con los usuarios y ayudarlos a manejar correctamente la entrada y salida. Para examinar las
razones subyacentes a la mayor parte del diseño que aprendió, es conveniente analizar las capacidades y limi-
taciones sensoriales humanas que deberán dar forma a nuestro diseño. De acuerdo con la filosofía de la HCI,
un analista debe ser capaz de compensar, solucionar o reemplazar los sentidos humanos hasta un cierto grado
variable.
VISIÓN En su esfuerzo por convertirse en analista de sistemas, se está empezando a acostumbrar a diseñar
pantallas e informes para las personas con discapacidad visual. El uso de color, fuentes, gráficas, software y
presentaciones de PowerPoint para las pantallas e informes impresos como entrada y salida se explicó con detalle
en los capítulos 11 y 12. Sin embargo, desde la perspectiva de la HCI, también es conveniente pensar en términos
de las limitaciones en la visión humana. Factores tales como la distancia entre la pantalla y la persona que realiza
una tarea, el ángulo de la pantalla en relación con la persona que la está viendo, el tamaño y la uniformidad de
los caracteres, el brillo, contraste, balance y resplandor de la pantalla, además del hecho de si está parpadeando o
fija son factores que se pueden diseñar en base a los estándares establecidos por medio de ISO y otras entidades
nacionales e internacionales.
OÍDO Los humanos también tienen límites en cuanto a la cantidad de estrés que pueden soportar. Las ruidosas
impresoras láser, las conversaciones telefónicas y las trituradoras de papel pueden provocar una sobrecarga en el
oído humano. Los trabajadores de oficina pueden usar audífonos supresores de ruido o conseguir un reproductor
de música personal como el iPod, pero estas soluciones pueden tener el efecto de aislar a una persona del entorno de
la organización, e incluso pueden disminuir su capacidad de realizar la tarea en cuestión. Como analista, usted
tendrá que considerar el ruido al diseñar sistemas de oficina.
TACTO Al usar una perspectiva de HCI para evaluar la utilidad de los teclados y demás dispositivos de entrada,
podemos clasificar el ajuste humano-computadora así como las dimensiones que examinan el ajuste humano-www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 449
computadora-tarea. Los teclados se diseñaron en forma ergonómica para proveer la retroalimentación correcta
para la persona que introduce datos. Con base en la firmeza de la tecla bajo su dedo, los usuarios saben que
se efectuó la pulsación de la misma. Aunque los teclados se pueden silenciar, a menudo se diseñan con un
clic de retroalimentación. Los teclados también incluyen marcas en relieve en lo que se denomina teclas base,
comúnmente la f y la j, las cuales orientan a los usuarios para que sepan la posición de sus dedos en el teclado de
manera que puedan ver a la pantalla o escribir información de una página impresa en su escritorio sin tener que
mirar continuamente el teclado.
Aunque el teclado QWERTY que utilizamos comúnmente con las computadoras en la actualidad se
diseñó para reducir la velocidad de los mecanógrafos, de manera que no se atoraran las teclas de las pri-
meras máquinas de escribir mecánicas, esta distribución del teclado ha demostrado ser una forma bastante
efectiva de introducir datos. De hecho, como los usuarios se desempeñan tan bien con esta familiar interfaz,
es difícil conducir experimentos para comparar la eficiencia de los teclados QWERTY con otros teclados
innovadores.
Diseñar para la introducción de datos mediante teclados numéricos también constituye una oportunidad de
decisión para los diseñadores. Observe los números en su teléfono celular, que están ordenados en forma distinta
a los números en un teclado numérico o calculadora. Es probable que su teléfono tenga los números 1, 2 y 3 en la
fila superior. Si da un vistazo a la distribución de una calculadora o un teclado numérico verá los números 7, 8 y 9
en la fila superior. La investigación ahora señala la superioridad de la distribución de la calculadora cuando el
usuario introduce muchos datos. Sin embargo, se supone que la distribución de los dígitos del teléfono es mejor
para localizar un número. Como diseñador, usted tiene que examinar de manera constante el ajuste entre el hu-
mano, la computadora y las tareas establecidas por la organización.
Consideración de las limitaciones, discapacidades y diseño de los humanos
Todos los humanos tienen limitaciones en sus capacidades físicas. Algunas se pueden ver de inmediato, otras no.
Al diseñar desde una perspectiva de HCI, usted empieza a descubrir que las limitaciones se describen con fre-
cuencia en términos de discapacidades. La aplicación de la HCI para apoyar y mejorar las capacidades físicas de
los humanos es una de las áreas de aplicación más prometedoras. Los grandes avances en ingeniería biomédica
implican que hay investigación encaminada a apoyar a personas con ciertos grados de discapacidad visual o au-
ditiva, y a las personas con movilidad limitada.
También hay mejoras en los soportes técnicos disponibles para quienes enfrentan dificultades en el proce-
samiento cognoscitivo, incluyendo a personas que sufren autismo, dislexia y trastorno de déficit de atención.
Como analista de sistemas, usted estará sujeto a las provisiones legales del país en el que trabaje. Por ejemplo,
si está diseñando lugares de trabajo en los Estados Unidos, tal vez sea conveniente que revise las obligaciones
de un patrón según la Ley de estadounidenses con discapacidades (ADA) en www.eeoc.gov/types/ada.html. Ahí
encontrará definiciones de quiénes se consideran discapacitados, la cual declara en parte que “Un individuo con
una discapacidad es una persona que tiene un impedimento físico o mental que limita en forma substancial una
o más actividades principales de vida, tiene un registro de dicho impedimento o se considera que tiene dicho im-
pedimento”.
Un patrón en los Estados Unidos tiene la obligación de hacer los ajustes necesarios para emplear a una
persona discapacitada, lo cual incluye “Hacer que las instalaciones existentes que utilizan los empleados sean
fácilmente accesibles y utilizables para las personas con discapacidades; reestructurar empleos, modificar los
horarios de trabajo, la reasignación a un puesto vacante; adquirir o modificar equipo o dispositivos, ajustar o mo-
dificar exámenes, material de capacitación o pólizas, y proveer lectores o intérpretes calificados”.
Un candidato o empleado calificado es un individuo que, “con o sin los ajustes razonables puede llevar a
cabo las funciones esenciales del empleo en cuestión”. Un patrón tiene la obligación de hacer los ajustes nece-
sarios en relación con la discapacidad conocida de un candidato o empleado calificado, siempre y cuando esto
no imponga un costo injustificado en la operación de la empresa. Costo injustificado se define como “una acción
que requiere una dificultad o gasto significativo en relación con factores tales como el tamaño del patrón, los re-
cursos financieros, la naturaleza y la estructura de su operación. Un patrón no tiene que reducir la calidad o los
estándares de producción para hacer dicho ajuste”.
Una de las mejores formas de asegurar que se haga el mayor grado de ajuste posible es empezar a diseñar
desde una perspectiva de HCI. De esa forma, su principal preocupación siempre será la de asistir a un usuario
en la realización de su tarea, establecida por la organización, mediante el uso de la tecnología. Cuando son ne-
cesarios los ajustes para personas discapacitadas, hay muchas fuentes qué examinar y muchos dispositivos de
asistencia qué considerar.
Para las personas con algún grado de discapacidad visual, hay teclados braille además de software especial
de voz que lee páginas Web y otros documentos en voz alta. También hay lupas de pantalla que se ajustan para
poder ampliar toda la pantalla completa.www.xlibros.com

450 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Para el caso de las personas que carecen de cierta sensibilidad al color (a lo que se le conoce erróneamente
como daltonismo), puede probar los colores que selecciona para las pantallas o formularios y asegurarse de que
se puedan diferenciar con facilidad unos de otros. Por ejemplo, hay problemas específicos que ocurren al tratar
de diferenciar el rojo y el verde. Diseñe siempre la pantalla o formulario con pistas alternativas, como iconos,
texto escrito o pistas de audio que refuercen el contenido. Por ejemplo, si al hacer clic en un hipervínculo éste
cambia a color azul para indicar que lo siguieron, también puede agregar otro icono a la pantalla para indicar que
lo siguieron o crear una lista en una barra lateral separada que muestre los sitios Web que se han visitado. Estas
son mejores alternativas que depender únicamente del color para transmitir el mensaje.
Para los usuarios que experimentan discapacidad auditiva, puede asegurarse de que los documentos y panta-
llas que diseñe incluyan el acceso a las versiones escritas del material de audio. La alternativa sería diseñar tareas
donde sea posible usar audífonos satisfactoriamente.
Si va a diseñar tareas de cómputo para los que tienen una movilidad limitada, puede pensar en usar la en-
trada de voz en vez del teclado. Además, los nuevos avances en la ingeniería biomédica permiten a los usuarios
con discapacidad móvil desplazar el cursor en la pantalla respirando a través de un tubo; también pueden dirigir
el cursor al punto deseado en la pantalla, para lo cual ven hacia ese punto o incluso, en ciertas interfaces muy
especializadas, sólo tienen que pensar hacia dónde se debería desplazar el cursor.
Implementación de las buenas prácticas de la HCI
Lo ideal es integrar a un especialista sobre usabilidad al equipo de desarrollo de sistemas. Sin embargo, mu-
chos grupos de sistemas son bastante pequeños y no hay muchos profesionales disponibles involucrados en
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 1
El espíritu escolar viene en varias tallas
Matt Scott administra el departamento de ropa de estudiantes y
ex alumnos para una extensa librería en Saratoga Springs.
“Nuestras ventas de ropa dependen no sólo de que pierden o
ganen nuestros equipos deportivos, sino también del bienestar en
general de nuestros estudiantes y ex alumnos. Si están orgullosos de
su universidad y desean mostrar su espíritu escolar comprarán todo
lo que haya en nuestros estantes”, exclama Matt. “Pero no hay que
subestimar el factor clima”, agrega. “Si éste se vuelve frío en octu-
bre, aumentará de manera repentina el número de personas que
compran suéteres cálidos, jerseys y guantes”.
“Nuestra tienda atiende a las tres principales universidades en
nuestra área”. Matt continúa: “En primer lugar, está Hyde Park, a la
que llamamos ‘escuela de fútbol’. Tienen aproximadamente 17,000
estudiantes y mucha demanda de ropa de marca de la escuela, en
especial en otoño. Y luego tenemos, desde luego, a la Pierce Uni-
versity. Los de Pierce creen que forman parte de la Ivy League, por
lo que a sus estudiantes les gusta comprar camisetas de cuello re-
dondo y tipo Lacrosse. Tienen aproximadamente 7,500 estudiantes.
También está St. David, con cerca de 3,000 estudiantes. Ellos están
dedicados a su equipo de básquetbol. Realmente tienen fe en ellos.
Podrá ver cómo aumentan las ventas en el segundo semestre, en
especial durante la ‘locura de marzo’”.
El Sr. Scott continúa y admite: “Pensé en preguntar a los estu-
diantes qué vender, pero una encuesta por correo electrónico queda
fuera de cuestión. Recibo mucho spam, por lo que la mayor parte
del tiempo no me molesto en usar el correo electrónico. Por desgra-
cia, el plazo de entrega para obtener la ropa deportiva de marca
oficial en la tienda es muy largo y existe el riesgo de quedarnos sin
existencias. Pero trataremos de que esto nunca pase”.
Le han pedido a usted que diseñe un conjunto de tablas y
gráficas que ayuden a analizar las ventas de la ropa de la escuela
de Matt Scott. Empiece con una lista de aproximadamente 20 ar-
tículos de ropa con marca de la escuela para fanáticos hombres y
mujeres, incluyendo artículos como sudaderas con capucha, cami-
setas, gorras de béisbol, bandas para la cabeza, shorts para correr,
etcétera. Muchos de estos artículos incluyen extravagantes diseños
adornados que describen a sus mascotas en poses amenazadoras o
atractivas. Hyde Park tiene sus cobradores dorados; Pierce a su
muy querida ave, Puffins; y St. David’s anima a su equipo con sus
dragones.
Coloque los elementos en categorías. Después piense sobre la
apariencia que deberían tener los datos. ¿Tiene sentido para Matt
ver los datos por semana, por mes o por semestre? ¿Le será conve-
niente revisar los datos con cinco años de antigüedad para ver si
hubo alguna tendencia? Establezca las tablas que identifican las
filas y las columnas, junto con el contenido de las celdas principa-
les. Sugiera varias tablas de manera que Matt pueda analizarlas en
distintas formas.
Ahora elabore gráficas que analicen los mismos datos. Use al-
gunos de los ejemplos incluidos en el libro para sugerir el tipo de
gráficas y muestre los datos de manera que distintos usuarios con
estilos diferentes puedan tomar algunas decisiones en relación con la
tendencia de las ventas durante los últimos años. Recuerde también
comparar las escuelas. Sugiera las gráficas apropiadas a usar: de co-
lumna, línea, trazos de dispersión o incluso gráficas de pastel.
Sugiera además tres o cuatro cambios específicos que realizaría
para permitir que alguien con cierto grado de discapacidad visual
pueda leer las gráficas con más facilidad. La ampliación es una forma
de cambiar una gráfica, pero tal vez no sea la mejor solución.
Considere el tamaño de las escuelas, ya que se puede convertir
en el factor más importante al determinar cómo debe Matt Scott
ajustar sus pedidos para St. David, Hyde y Pierce.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 451
Lineamientos de la metodología de la HCI para el diseño de sistemas
• Examine la tarea a realizar y considere el ajuste entre humano, computadora y tarea.
• Identifique los obstáculos que existen para los usuarios al tratar de cumplir con sus tareas asignadas.
• Tenga en cuenta la utilidad y la facilidad de uso percibidas del TAM.
• Considere la usabilidad. Examine el entorno de uso mediante la creación de escenarios de casos de
uso que describan lo que ocurre entre los usuarios y la tecnología.
• Use la información que haya obtenido de antemano para definir las características
ambientales físicas y organizacionales. Diseñe y use prototipos para adaptarse a los diversos usuarios
y a los usuarios con discapacidades.
FIGURA 14.8
La metodología de la HCI para el
diseño de sistemas hace énfasis en
el ajuste entre humano,
computadora y tarea.
la práctica de la usabilidad como tal; así, aunque intente introducir este cambio en su proyecto, es muy pro-
bable que el puesto quede vacante o que batalle mucho con el personal. Pero no deje que esto lo desanime.
Puede llevar a cabo algunos pasos simples que influirán en forma positiva en el resultado de su proyecto de
sistemas. La figura 14.8 muestra una lista de los lineamientos para aplicar una metodología de HCI en el
diseño de sistemas.
Aunque hemos estado describiendo el sistema en abstracto, es importante reconocer que la interfaz es el
sistema para la mayoría de los usuarios. Sin importar qué tan bien o mal diseñada esté, representa al sistema y
refleja su competencia como analista de sistemas. Una interfaz bien diseñada mejora el ajuste entre la tarea, la
tecnología y el usuario.
Su objetivo debe ser diseñar interfaces que ayuden a los usuarios y las empresas a introducir la informa-
ción al sistema y obtener de éste la información que necesitan, para lo cual hay que considerar los siguientes
objetivos:
1. Hacer que la interfaz de usuario corresponda con la tarea.
2. Hacer la interfaz de usuario eficiente.
3. Proveer una retroalimentación apropiada a los usuarios.
4. Generar consultas que se puedan utilizar.
5. Mejorar la productividad de los usuarios de computadora.
TIPOS DE INTERFAZ DE USUARIO
En esta sección describiremos distintos tipos de interfaces de usuario, incluyendo las de lenguaje natural, las de
preguntas y respuestas, los menús, las interfaces de llenado de formularios, las interfaces de lenguaje de coman-
dos, las interfaces gráficas de usuario (GUI) y otras interfaces Web para usar en Internet. La interfaz de usuario
tiene dos componentes principales: el lenguaje de presentación, que es la parte de la transacción de la compu-
tadora al humano, y el lenguaje de acción, que caracteriza la parte del humano a la computadora. En conjunto,
ambos conceptos abarcan la forma y el contenido del término interfaz de usuario.
Interfaces de lenguaje natural
Las interfaces de lenguaje natural son tal vez el sueño y el ideal de los usuarios sin experiencia, ya que no
requieren tener habilidades especiales y pueden interactuar con la computadora mediante el uso de lenguaje
natural.
La pantalla que se muestra en la figura 14.9 incluye una lista de tres preguntas en lenguaje natural para
tres aplicaciones. Observe que la interacción con cada pregunta se ve muy sencilla. Por ejemplo, el primer
enunciado parece bastante simple y directo: “Mencione los vendedores que cumplieron con sus cuotas este
mes”.
Las ambigüedades naturales de algunos idiomas, como el inglés y en menor medida el español, producen
arduos problemas de programación. Los intentos de crear interfaces en lenguaje natural para ciertas aplica-
ciones en las que cualquier otro tipo de interfaz no sería viable (por ejemplo, en el caso de un usuario disca-
pacitado) están teniendo algo de éxito; sin embargo, comúnmente estas interfaces son costosas. Hasta ahora,
los problemas de implementación y la extraordinaria demanda de recursos de cómputo han mantenido el uso
de las interfaces de lenguaje natural al mínimo. Pero la demanda existe, por lo que muchos programadores e
investigadores están trabajando con diligencia en ellas. Es un área de crecimiento, por lo que amerita mante-
nerse al tanto de ella.www.xlibros.com

452 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Interfaces de preguntas y respuestas
En una interfaz de preguntas y respuestas, la computadora despliega una pregunta para el usuario en la panta-
lla. Para interactuar, el usuario introduce una respuesta (mediante una pulsación de tecla o un clic del ratón) y
después la computadora actúa con base en esa información de entrada en forma preprogramada, por lo general
avanzando a la siguiente pregunta.
En la figura 14.10 se muestra un tipo de interfaz de preguntas y respuestas, conocido como cuadro de diá-
logo. Un cuadro de diálogo actúa como una interfaz de preguntas y respuestas dentro de otra aplicación, en este
> Mencione los vendedores que cumplieron con sus metas este mes.
> Compare el porcentaje de productos echados a perder en cada una de nuestras
tres tiendas.
> Grafique la venta de unidades de DVD por mes durante los últimos tres años.
Tom Otto
Roz Berry
Spin Etch
Fair Oaks 4%
Tyson’s 5%
Metro Center 3%
Oprima cualquier tecla para continuar.
FIGURA 14.9
Interfaces de lenguaje natural.
9/24
10/22
10/22
10/22
10/22
Administrar
cuestionario
Entrevistar a
B. Crieghton
Crear prototipo
de entrada
Desarrollar base
de datos
Crear prototipo
de salida
Resolver
información en
conflicto
¿Guardar cambios antes de salir?
Sí
CancelarNo
Proyecto Bakerloo Bros.
Archivo Edición Gráfica Tarea Distribución Fechas Fuentes Estilo
FIGURA 14.10
Un cuadro de diálogo: un tipo de
interfaz de preguntas y respuestas.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 453
caso una gráfica de PERT para un proyecto de análisis de sistemas para Bakerloo Brothers. Observe que el rec-
tángulo redondeado para la opción “Sí” está resaltado para indicar que es la respuesta más probable en esa situa-
ción. La interfaz principal para esta aplicación no necesita ser de preguntas y respuestas. Más bien, mediante la
incorporación de un cuadro de diálogo el programador ha incluido una interfaz fácil de usar dentro de una más
complicada.
Los asistentes que se utilizan para instalar software son un ejemplo común de una interfaz de preguntas y
respuestas. El usuario responde a las preguntas sobre el proceso de instalación, como dónde instalar el software
o las herramientas. El asistente también puede hacer preguntas y responder a las preguntas del usuario con más
preguntas diseñadas para reducir el alcance del problema. Ésta es una manera típica de establecer una interfaz de
soporte técnico para reducir los problemas y diagnosticarlos con más precisión.
Menús
Una interfaz de menú toma debidamente prestado el nombre de la lista de platillos que se pueden selec-
cionar en un restaurante, pues de manera similar, provee al usuario una lista en pantalla de las selecciones
disponibles.
Para responder al menú, el usuario está limitado a las opciones que se muestran en la pantalla. El usuario no
tiene que conocer el sistema, pero sí necesita saber qué tarea debe realizar. Por ejemplo, en un menú típico de
un procesador de palabras, los usuarios pueden elegir las opciones Edición, Copiar o Imprimir, pero para usar el
menú con eficiencia, los usuarios deben saber qué tarea desean realizar.
Los menús no dependen del hardware. Las variedades abundan. Se pueden configurar para usar la entrada
desde el teclado, un lápiz óptico, pantalla táctil o ratón. Las selecciones se pueden identificar mediante un nú-
mero, una letra o una palabra clave, o los usuarios pueden hacer clic en una selección con un ratón. La consisten-
cia es importante al diseñar una interfaz de menú.
Los menús también se pueden hacer a un lado hasta que el usuario los necesite. La figura 14.11 muestra
cómo el usuario utiliza un menú desplegable mientras construye un diagrama PERT para un proyecto de análisis
de sistemas que está terminando para Bakerloo Brothers. El usuario coloca el puntero en Fechas y despliega el
menú hacia abajo. Después coloca el puntero en Calendario y selecciona la opción para mostrar el proyecto en
un calendario mensual convencional.
Los menús se pueden anidar unos dentro de otros para conducir a un usuario por las opciones en un pro-
grama. Los menús anidados permiten que la pantalla aparezca menos desordenada, la cual es consistente con el
buen diseño. También permiten a los usuarios evitar ver las opciones de menú que no les interesan. Los menús
anidados también pueden desplazar a los usuarios rápidamente por el programa.
9/24
10/22
10/22
10/22
10/22
Administrar
cuestionario
Entrevistar a
B. Crieghton
Crear prototipo
de entrada
Desarrollar
base de datos
Crear prototipo
de salida
Resolver
información
en conflicto
Mostrar Fechas M
Establecer Primer Inicio P
Establecer Final Más Reciente M
Escala de Duración D
Escala de Línea del Tiempo T
Calendar C
Archivo Edición Gráfica Tarea Distribución Fechas Fuentes Estilo
FIGURA 14.11
Un menú desplegable está ahí
cuando el usuario lo necesita.www.xlibros.com

454 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 2
Preferiría hacerlo yo mismo
“Puedo pedir a Mickey que descargue los datos que necesito
de la Web o de nuestro servidor a mi PC”, le dice DeWitt
Miwaye, un gerente de nivel superior para Yumtime Foods (una
empresa mayorista de alimentos de la región del Medio Oeste).
“Obtener los datos no es problema. Lo que no quiero son mu-
chos informes. Preferiría obtener los datos yo mismo”.
Miwaye continúa y le dice que, como ejecutivo, no uti-
liza su PC tanto como quisiera, tal vez sólo tres veces al mes,
pero tiene algunas ideas muy específicas sobre lo que le gus-
taría hacer con ella.
“Me gustaría poder realizar algunas comparaciones por mi propia
cuenta. Podría comparar la tasa de rotación para todos nuestros 12 alma-
cenes. También me gustaría ver con qué eficiencia se utiliza la capacidad
de cada uno de nuestros almacenes. Algunas veces quisiera poder grafi-
car las comparaciones o ver un diagrama de ellas a través del tiempo”.
Compare en tres párrafos los tres tipos de interfaces que Miwaye
podría usar. Después recomiende una interfaz que pueda usar y que
tome en cuenta su uso infrecuente de la PC, el hecho de que disfruta
trabajar con datos crudos y su deseo de ver los datos en pantalla de
varias formas.
Los menús de GUI se utilizan para controlar el software de PC y tienen los siguientes lineamientos:
1. La barra de menús principal siempre se muestra.
2. El menú principal usa una sola palabra para los elementos de menú. Las opciones del menú principal
siempre muestran menús desplegables secundarios.
3. El menú principal debe tener opciones secundarias agrupadas en conjuntos similares de características.
4. Los menús desplegables que aparecen al hacer clic en un elemento del menú principal consisten a menudo
de más de una palabra.
5. Las opciones secundarias desempeñan acciones o muestran elementos de menú adicionales en pantalla.
6. Los elementos de menú en gris no están disponibles para la actividad actual.
Un menú de objeto, también conocido como menú contextual, aparece cuando el usuario hace clic en un ob-
jeto de la GUI con el botón derecho del ratón. Estos menús contienen elementos específicos para la actividad en
curso y la mayoría son funciones duplicadas de los elementos del menú principal.
Los usuarios experimentados podrían molestarse con los menús anidados. Tal vez prefieran usar una entrada
de comando de una sola línea para agilizar las cosas. Otros usuarios podrían usar las teclas de método abreviado
o combinaciones de teclas tales como Alt .I .P C, que inserta una imagen prediseñada en un documento de
Microsoft Office.
Interfaces de llenado de formularios (formularios de entrada/salida)
Las interfaces de llenado de formularios consisten en formularios en pantalla o basados en Web que muestran los
campos que contienen elementos de datos o parámetros necesarios para comunicarse con el usuario. A menudo
el formulario es un facsímil de un formulario en papel ya conocido por el usuario. Esta técnica de interfaz se
conoce también como método basado en formulario y formularios de entrada/salida.
La figura 14.12 muestra una interfaz de llenado de formulario. Un menú desplegable para Núm. Pieza in-
troduce en forma automática una Descripción y un Precio Unitario para el artículo. Cuando el usuario usa el
tabulador para cambiar al campo Cantidad e introduce el número de elementos que desea comprar, el software
calcula de manera automática el Precio Extendido al multiplicar Cantidad por Precio Unitario.
Los formularios para las pantallas de visualización se establecen para mostrar qué información se debe in-
troducir y dónde hay que hacerlo. Los campos en blanco que requieren información se pueden resaltar con ca-
racteres inversos o destellantes. El usuario desplaza el cursor de un campo a otro al oprimir una tecla de flecha.
Esta disposición le permite desplazarse un campo hacia atrás o un campo hacia delante con sólo hacer clic en
la tecla de flecha apropiada. Provee al usuario un buen control al momento de introducir datos. Los formularios
basados en Web ofrecen la oportunidad de incluir hipervínculos a ejemplos de formularios completados en forma
correcta, o hipervínculos donde el usuario puede obtener más ayuda y ejemplos.
Podemos simplificar la entrada de los formularios para las pantallas si proveemos valores predeterminados
para los campos y después permitimos a los usuarios modificar la información predeterminada, en caso de ser
necesario. Por ejemplo, un sistema de administración de bases de datos diseñado para mostrar un formulariowww.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 455
Blocs de notas, 4 pulg. X 5 pulg., caja de 25
Cinta transparente, 12mm x 33mm, caja de 12
Hi-Liter, colores surtidos, caja de 12
Orden de compra
Fecha del pedido Requerido por Núm. de requisa
(MM/DD/AAAA) (MM/DD/AAAA)
Nombre y dirección del distribuidor Enviar a
Núm. Pieza Descripción Cantidad Precio
unitario
Precio
extendido
FIGURA 14.12
Un ejemplo de la interfaz de
llenado de formularios.
para introducir cheques puede proveer el siguiente número de cheque secuencial como valor predeterminado al
momento de exhibir el formulario del cheque nuevo. Si faltan cheques, el usuario modifica el número de cheque
para reflejar el cheque actual que se está introduciendo.
La entrada para los campos de las pantallas de visualización se puede restringir al formato alfanumérico para que,
por ejemplo, los usuarios puedan introducir sólo números en un campo que solicite un número de Seguro social, o que
puedan introducir sólo letras donde se requiera el nombre de una persona. Si se introducen números donde sólo se per-
miten letras, la computadora puede alertar al usuario mediante un sonido que el campo se llenó en forma incorrecta.
La principal ventaja de la interfaz del formulario de entrada/salida es que la versión impresa del formula-
rio de llenado provee una excelente documentación. Muestra las etiquetas de los campos, así como el contexto
para las entradas. Además, los formularios Web pueden devolver formularios incompletos al usuario con una
explicación de los datos que se deben introducir para completar la transacción. A menudo, los campos con datos
faltantes se marcan con un asterisco de color rojo. Los documentos basados en Web se pueden enviar de manera
directa a facturación si hay una transacción involucrada, o pueden ir directamente a una base de datos en tiempo
real si se va a enviar una encuesta. Los formularios basados en Web pasan la responsabilidad de la precisión al
usuario y ponen el formulario a su disposición para que lo completen y envíen las 24 horas del día, los 7 días de
la semana en cualquier parte del mundo.
Hay unas cuantas desventajas en los formularios de entrada/salida. La principal desventaja es que los usua-
rios experimentados en el sistema o una aplicación podrían impacientarse con los formularios de entrada/salida y
podrían garantizar maneras más eficientes de introducir datos.
Interfaces de lenguaje de comandos
Una interfaz de lenguaje de comandos permite al usuario controlar la aplicación mediante una serie de pulsacio-
nes de tecla, comandos, frases o alguna secuencia de estos tres métodos. Las sintaxis simples de los lenguajes de
comandos se consideran cercanas al lenguaje natural.
En la figura 14.13 se muestran dos ejemplos de aplicación del lenguaje de comandos. El primero muestra a
un usuario que pide usar un archivo con datos sobre todos los vendedores y después pide a la computadora que
muestre todos los apellidos paternos y nombres de pila para todos los vendedores cuyas ventas actuales (VEN-
TACT) sean mayores que sus cuotas. En el segundo ejemplo, un usuario pide usar un archivo llamado ABARR
y después instruye a la computadora que calcule los desperdicios (DESPERD), para lo cual hay que restar los
productos vendidos de los productos comprados. Después de eso el usuario pide regresar a la parte superior del
archivo para imprimirlo (LISTA).
El lenguaje de comandos no tiene un significado inherente para el usuario; esto lo diferencia de las demás
interfaces descritas. Los lenguajes de comandos manipulan la computadora como una herramienta al permitir
que el usuario controle el diálogo. El lenguaje de comandos ofrece al usuario más flexibilidad y control en ge-
neral. Cuando el usuario emplea el lenguaje de comandos, el sistema ejecuta el comando de inmediato; así, el
usuario puede darle otro comando.
Los lenguajes de comandos requieren la memorización de reglas de sintaxis, lo que puede constituir un obs-
táculo para los usuarios inexpertos. Los usuarios expertos tienden a preferir los lenguajes de comandos, posible-
mente debido a que se llevan a cabo con mucha más rapidez.www.xlibros.com

456 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Interfaces gráficas de usuario
La clave para las interfaces gráficas de usuario (GUI) es la retroalimentación constante en la realización de las
tareas que proveen a los usuarios. La retroalimentación continua sobre el objeto manipulado significa que se pue-
den cambiar o invertir las operaciones con rapidez, sin incurrir en mensajes de error.
La creación de GUI impone un reto, pues hay que inventar un modelo apropiado de la realidad o un modelo
conceptual aceptable de la representación. Para diseñar GUI que se utilicen en intranets, extranets y en la Web
se requiere una planeación todavía más cuidadosa. La mayoría de los usuarios de sitios Web son desconocidos
para el desarrollador, por lo que el diseño debe estar bien definido. La elección de iconos, lenguaje e hipervíncu-
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 3
No me desaceleren
“Las he visto todas”, le comenta Carrie Moore. “Estuve aquí
cuando obtuvieron su primer sistema de cómputo. Creo que hasta
he hecho una carrera de esto”, dice alegremente mientras apunta a
la gran pila de formularios de reclamaciones de seguros médicos
que ha estado introduciendo en el sistema de cómputo. Como ana-
lista de sistemas usted está entrevistando a Carrie, una capturista de
datos para AbundaCare (una empresa grande de seguros médicos),
sobre los cambios que se contemplan en el sistema de cómputo.
“Soy realmente rápida en comparación con los demás”, dice
mientras señala con la cabeza hacia los otros seis capturistas de la
sala. “Lo sé porque tenemos pequeños concursos todo el tiempo
para ver quién es el más rápido, con la menor cantidad de errores.
¿Ve esa tabla en la pared? Muestra cuántos datos hemos introducido
y con qué rapidez. Las estrellas doradas muestran quién es el mejor
cada semana. Las medidas de desempeño son mis amigas”.
“En realidad no me importa si cambia las computadoras. Como
dije, ‘las he visto todas’”. Vuelve a teclear en su equipo mientras
continúa con la entrevista. “Pero cualquier cosa que vaya a hacer,
no me desacelere. Una de las cosas que más me enorgullecen es que
todavía puedo vencer a los otros capturistas, que también son bue-
nos”, agrega Carrie.
Con base en esta entrevista parcial con Carrie Moore, ¿qué tipo
de interfaz de usuario diseñará para ella y los otros operadores?
Suponga que incluso cuando el nuevo sistema está mejorado, de to-
das formas requerirá la introducción de cantidades masivas de datos
provenientes de variedad de formularios de seguros médicos envia-
dos por los solicitantes.
Compare y contraste en dos párrafos las interfaces como la de len-
guaje natural, de preguntas y respuestas, menús, formularios de entrada/
salida, y documentos de llenado basados en Web. Después seleccione
y defienda una alternativa. ¿Qué cualidades de las que poseen Carrie y
los otros capturistas (además de los datos que van a introducir) deter-
minaron su elección? Haga una lista. ¿Hay más de una opción viable?
¿Por qué sí o por qué no? Responda en un párrafo.
USAR VENDEDOR
MOSTRAR TODO APELLIDO, NOMBRE PARA VENTACT > CUOTA
USAR ABARR
REEMPLAZAR TODO DESPERD CON PCOMPRADOS – PVENDIDOS
IRA SUPERIOR
LISTA
FIGURA 14.13
Interfaces de lenguaje de
comandos.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 457
los se convierte en todo un conjunto completo de decisiones y suposiciones sobre los tipos de usuarios que es-
pera atraer el sitio Web. El diseñador también debe adherirse a las convenciones que los usuarios esperan ahora
encontrar en los sitios Web.
Otras interfaces de usuario
Hay otras interfaces de usuario menos comunes que están creciendo en popularidad: dispositivos señaladores
como plumillas, pantallas sensibles al tacto, reconocimiento de voz y síntesis, etc. Cada una de estas interfaces
tiene sus propios atributos especiales que la adaptan en forma única a ciertas aplicaciones.
La plumilla (un pequeño dispositivo con punta que se asemeja a una pluma) se utiliza con el software de
reconocimiento de escritura para teléfonos móviles (que actúan como PDA: asistentes personales digitales) y
dispositivos de PC. Han sido un éxito debido a que integran muchas funciones y son fáciles de usar. Además son
portátiles y se venden a un precio relativamente bajo. Han surgido muchas aplicaciones divertidas y útiles escri-
tas para estos dispositivos móviles, incluyendo programas populares para reseñas de restaurantes como Zagat,
herramientas populares como listas de “tareas pendientes” para uso de trabajo y personal, y para juegos popula-
res como Sudoku. También se facilita el proceso de introducir datos mediante una base de acoplamiento, de ma-
nera que se puedan sincronizar los datos con su PC.
Una Tablet PC es una computadora tipo notebook con una pantalla sensible al tacto. Puede estar equipada
con conexión Wi-Fi o Bluetooth. Las pantallas sensibles al tacto permiten al usuario usar un dedo o una plumilla
para operarlas. Son útiles para visualizar información pública, como mapas de las ciudades y sus vistas publi-
cados en vestíbulos de hoteles o locales de renta de automóviles. También se pueden usar para explicar piezas
de exhibición en los museos y localizar lugares para acampar en los parques estatales. Las pantallas sensibles al
tacto no requieren que los usuarios tengan una experiencia especial; además la pantalla es autocontenida, por lo
que no requiere de ningún dispositivo especial de entrada que alguien podría quebrar o robar. Las pantallas sen-
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 4
Ésa no es una bombilla
A partir del análisis preliminar que usted realizó, se desprende que
habría una considerable reducción en la cantidad de errores si los
vendedores en Bright’s Electric (que vende piezas eléctricas, bulbos
y accesorios a clientes de mayoreo) adoptan un sistema en línea. El
nuevo sistema permitiría a los vendedores retirar una pieza del inven-
tario (y por lo tanto actualizar el inventario), devolver una pieza al
inventario, revisar el estado del inventario y verificar si una pieza está
en pedido pendiente. En la actualidad, para actualizar el inventario los
vendedores llenan un formulario a mano con dos copias y un original.
El cliente recibe una copia, el inventario recibe una y al final del día
los originales se depositan en la oficina frontal.
La siguiente mañana, lo primero que hace el solitario trabaja-
dor de oficina es introducir los datos de los formularios en la compu-
tadora. Se producen errores cuando introduce los números de pieza
o las cantidades incorrectas. Se consume tiempo adicional cuando
los trabajadores del inventario buscan una pieza que creen que po-
dría tener existencia, pero no es así. Hay hojas de inventario actua-
lizado disponibles para los vendedores cerca de mediodía, pero para
esas horas ya han sacado del inventario el doble del número de
piezas que sacarán después de mediodía. Sin duda, un sistema en
línea bien diseñado ayudaría a reducir estos errores y también ayu-
daría con el control del inventario.
El propietario, Luis Bright, ha contemplado la idea de un sistema
en línea y la ha descartado varias veces durante los últimos cinco años.
La principal razón es que los vendedores, que serían los usuarios más
frecuentes del sistema, no creen que los analistas de sistemas con los
que han hablado puedan crear un sistema realmente útil.
M. T. Sockette, el vendedor que ha estado más tiempo con
Bright’s Electric, es el que más habla de todos y le dice: “Conoce-
mos las piezas, conocemos a nuestros clientes. Lo que podríamos
hacer aquí con una computadora sería grandioso. Pero los que han
venido aquí para tratar de hacer algo... bueno, dicen cosas como:
‘Ahora puedes introducir una bombilla CFL General Electric de 60
Watts en la computadora’”.
“Para nosotros esa no es una bombilla, es un GE60WCFL.
Todos aquí conocemos los números de las piezas. Nos enorgullece-
mos de ello. Escribir toda esa basura nos tomará todo el día”.
Después de hablar con el Sr. Bright, usted decide implementar
un sistema en línea. Ya habló con M. T. y los demás para volver a
asegurarles que el sistema utilizará los números de pieza con los que
están familiarizados y les ahorrará tiempo. Aunque son escépticos,
usted los ha persuadido de hacer un intento.
¿Qué tipo de interfaz de usuario diseñará para los vendedo-
res? Antes de llegar a su solución, haga un análisis cuidadoso en
tres párrafos en el que compare y contraste varias interfaces de
usuario (lenguaje natural, preguntas y respuestas, menús, formula-
rios de entrada/salida, lenguaje de comandos y documentos de
llenado de formularios basados en Web) en cuanto a la forma en
que se podrían adaptar en Bright’s. Después seleccione una inter-
faz y explique en un párrafo por qué le parece la más apropiada con
base en lo que sabe acerca de los vendedores de Bright’s y su sis-
tema actual. Dibuje un prototipo de una pantalla que será parte de
su solución. Describa en un párrafo cómo probará su usabilidad
con los vendedores.www.xlibros.com

458 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
sibles al tacto (también conocidas simplemente como pantallas táctiles o tabletas táctiles) para los teléfonos mó-
viles como el iPhone y la BlackBerry están convirtiendo esta interfaz de usuario alternativa en algo familiar y de
uso extendido. Las investigaciones recientes examinan la forma de poder comercializar las tabletas táctiles sensi-
bles a presión. Estas interfaces se pueden usar con pantallas táctiles tanto grandes como pequeñas y son prácticas
para las aplicaciones como la pintura o escultura virtual, un ratón simulado y para instrumentos musicales como
un teclado de piano, donde la intensidad de la presión aplicada es crucial para la salida.
Con el reconocimiento de voz, el usuario habla a la computadora y el sistema es capaz de reconocer las
señales de voz de un individuo, convertirlas y almacenar la entrada. El reconocimiento de voz en los sistemas
de inventario ya se encuentra en operación; los automóviles ahora incluyen sistemas de entrada de voz que res-
ponden a los comandos de voz del conductor para navegar, cambiar la estación de radio o usar un teléfono con
Bluetooth conectado al vehículo.
Una ventaja de los sistemas de reconocimiento de voz es que pueden agilizar la entrada de datos en forma
considerable, además de que liberan las manos del usuario para otras tareas (como conducir, por ejemplo). La
entrada de voz agrega otra dimensión a la PC: ahora es posible agregar equipo y software que permita al usuario
de una PC hablar los comandos como “abrir archivo” o “guardar archivo” para no tener que usar el teclado o el
ratón. Los usuarios con movilidad limitada o discapacidad visual se pueden beneficiar de los sistemas de recono-
cimiento de voz. En el ejemplo que se muestra en la figura 14.14, para corregir una palabra el usuario despliega
un menú de palabras alternativas parecidas.
Al evaluar las interfaces hay que tener en cuenta ciertos estándares:
1. El periodo de capacitación necesario para los usuarios debe ser razonablemente corto.
2. En las primeras etapas de su capacitación, los usuarios deben ser capaces de introducir los comandos sin
pensar en ellos o tener que consultar un menú o manual de ayuda. Mantener las interfaces consistentes en
todas las aplicaciones es conveniente en este caso.
3. La interfaz debe ser transparente, de manera que haya pocos errores y los que ocurran no se deban a un mal diseño.
4. El tiempo que los usuarios y el sistema necesitan para recuperarse de los errores debe ser corto.
5. Los usuarios infrecuentes deben ser capaces de volver a aprender a usar el sistema rápidamente.
Hay muchas interfaces distintas disponibles, por lo que es importante tener en cuenta que una interfaz efec-
tiva requiere de mucho esfuerzo para poder lidiar con las cuestiones clave de la HCI. Tal vez los usuarios quieran
usar el sistema, por lo que debe parecerles atractivo, eficiente y divertido de usar.
LINEAMIENTOS PARA EL DISEÑO DEL DIÁLOGO
El diálogo es la comunicación entre la computadora y una persona. Un diálogo bien diseñado facilita a las perso-
nas el proceso de usar una computadora y reduce su frustración con el sistema de cómputo.
Sugerencias prácticas para
desarrollar un sitio Web
Acostumbre
acostumbre
Acosar
Use herramientas profesi
Estudie otros sitios Web
Use los recursos que
Examine los sitios Web de
Acostúmbrese a las herrar
Consulte los libros
Vea algunos malos ejemplos de páginas Web
Cree sus propias plantillas
Acostúmbrese
FIGURA 14.14
Mediante el uso de software como
Dragon NaturallySpeaking de
Nuance, un usuario puede decir
los comandos en su computadora.
En este ejemplo, para corregir una
palabra el usuario despliega un
menú de palabras alternativas que
suenan igual.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 459
Como recordará, los elementos del TAM (modelo de aceptación de tecnología) indican que la utilidad y la
facilidad de uso percibidas tempranamente provocarán en el usuario la intención de usar el sistema y, en un mo-
mento dado, empezará a utilizarlo. Hay varios puntos clave para diseñar un buen diálogo:
1. Una comunicación significativa, de manera que la computadora comprenda lo que las personas introducen y
las personas comprendan lo que la computadora presenta o solicita.
2. Una mínima acción por parte del usuario.
3. Operación y consistencia estándar.
Comunicación significativa
El sistema debe presentar con claridad la información al usuario. Esto significa tener un título apropiado para
cada pantalla, minimizar el uso de las abreviaturas y proveer una retroalimentación clara al usuario. Los pro-
gramas de investigación deben mostrar los significados del código así como los datos en un formato editado;
por ejemplo, mostrar barras diagonales entre el mes, día y año en un campo de fecha o las comas y los puntos
decimales en un campo de cantidad monetaria. Hay que proveer instrucciones para el usuario en relación con
los detalles, como las asignaciones disponibles para las teclas de función. En una interfaz gráfica de usuario, el
cursor puede cambiar de forma dependiendo del trabajo que se esté realizando.
Los usuarios con menos habilidad para usar la computadora o los que realizan sus tareas con una compu-
tadora requieren de mayor comunicación. Los sitios Web deben mostrar más texto e instrucciones para guiar al
usuario por todo el sitio. Los sitios de intranets pueden tener menos diálogo, ya que hay requerimientos mínimos
en cuanto al grado de capacitación de los usuarios. Las imágenes de Internet deben tener descripciones de texto
desplegables o de sustitución cuando se utilicen imágenes como hipervínculos, ya que puede haber incertidum-
bre al interpretar su significado, en especial si el sitio se utiliza a nivel internacional. Cabe mencionar que los
lineamientos de la UE para la visualización de imágenes Web requieren que todas ellas estén etiquetadas, para
que los usuarios con discapacidad visual puedan escuchar cuando se anuncien descripciones escritas por medio
de software especial. La información de la línea de estado para las pantallas de GUI es otra forma de proveer
instrucciones para los usuarios.
Además hay que proporcionar pantallas de ayuda fáciles de usar. Muchas pantallas de ayuda de PC tienen
temas adicionales que se pueden seleccionar de manera directa mediante el uso de texto resaltado en la primera
pantalla de ayuda. Por lo general, estos hipervínculos están en un color distinto, lo cual los hace resaltar en
contraste con el resto del texto de ayuda. Recuerde usar iconos o texto además de la codificación de color para
poder hacer contacto con la mayor cantidad de usuarios que sea posible. Muchas GUI incorporan la ayuda me-
diante cuadros de información sobre las herramientas, donde se muestra un pequeño mensaje de ayuda para
identificar la función de un botón de comando cuando se coloca el cursor encima de éste. El otro lado de la co-
municación es que la computadora debe comprender lo que introdujo el usuario. Por ende, hay que editar todos
los datos que se introduzcan en la pantalla para que sean válidos.
Mínima acción por parte del usuario
La acción de teclear es a menudo la parte más lenta de un sistema de cómputo, por lo que un buen diálogo mini-
mizará el número de pulsaciones de tecla requeridos. Podemos lograr esto de varias formas distintas:
1. Teclear códigos en las pantallas de entrada, como los códigos de aeropuertos al hacer una reservación
de un vuelo, en vez de palabras completas. Los códigos también se teclean cuando se utiliza una interfaz
de lenguaje de comandos, como una abreviación postal de dos letras para los estados. En una GUI, los
códigos se pueden introducir mediante la selección de descripciones de los códigos de una lista desplegable
de opciones disponibles. Esto ayuda a asegurar la precisión, ya que el código se almacena como un valor de
la lista desplegable; además ayuda a proveer una comunicación significativa, ya que se seleccionan
descripciones familiares para el usuario. Un ejemplo sería seleccionar una provincia canadiense y hacer
que se almacene el código postal de dos caracteres.
2. Introducir sólo datos que no estén ya almacenados en los archivos. Por ejemplo, al modificar o
eliminar registros de artículos, sólo hay que introducir el número del artículo. La computadora
responde mostrando la información descriptiva que se encuentra almacenada en el archivo de artículos.
Otro ejemplo es cuando un usuario inicia sesión en un sitio Web y se utiliza el ID de usuario para
buscar los registros relacionados tales como el registro de clientes, las facturas pendientes, los pedidos,
etcétera.
3. Proveer los caracteres de edición (por ejemplo, las barras diagonales como separadores de campos de
fecha). Los usuarios no deberían tener que introducir caracteres de formato como ceros a la izquierda,
comas o un punto decimal al introducir montos de dinero; tampoco barras diagonales o guiones al
introducir una fecha. En general, los sitios Web son una excepción a esta regla, ya que los formularioswww.xlibros.com

460 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Web no incluyen barras diagonales ni puntos decimales. Algunos formularios Web utilizan una serie de
campos de entrada con caracteres de edición entre ellos, como los paréntesis alrededor de un código
de área.
4. Usar valores predeterminados para los campos en las pantallas de entrada. Los valores predeterminados
se utilizan cuando el usuario introduce el mismo valor en un campo de pantalla para la mayoría de los
registros que se están procesando. El valor se muestra y el usuario puede oprimir Intro para aceptar el valor
predeterminado, o sobrescribirlo con uno nuevo. Las GUI pueden contener casillas de verificación y botones
de opción que se seleccionen al abrir un formulario Web o cuadro de diálogo. Los menús sensibles al
contexto aparecen cuando se hace clic en un objeto con el botón derecho del ratón. Estos menús contienen
opciones específicas para el objeto que está debajo del ratón.
5. Diseñar un programa de consulta (o de modificación, o eliminación) de manera que el usuario necesite
introducir sólo los primeros caracteres de un nombre o la descripción de un artículo. El programa muestra
una lista de todos los nombres que coincidan y, cuando el usuario selecciona uno, se muestra el registro
correspondiente.
6. Proveer pulsaciones de tecla para seleccionar las opciones de los menús desplegables. A menudo estas
opciones se seleccionan mediante un ratón y después se pulsa una tecla. A medida que los usuarios se van
familiarizando con el sistema, las teclas de método abreviado ofrecen un método más rápido para manipular
los menús desplegables, ya que ambas manos permanecen en el teclado. Esto ayuda a los usuarios a volverse
eficientes en sus tareas. En una PC o Mac, las pulsaciones de tecla por lo general requieren que se oprima
una tecla de función o la tecla Alt seguida de una letra. La figura 14.15 es un ejemplo de menús desplegables
anidados.
7. Usar botones de opción y listas desplegables para controlar las pantallas de nuevas páginas Web o
modificar formularios Web. Por ejemplo, hacer clic en un botón de opción puede cambiar una lista
desplegable para reflejar el botón de opción que se seleccionó. Se puede hacer clic en un botón de opción y
un formulario puede cambiar de acuerdo con la selección. Una lista desplegable puede cambiar o se puede
hacer clic en un botón de opción para ir a una nueva página Web. A menudo las listas desplegables se
proveen en una página Web para navegar con rapidez; al seleccionar una nueva página Web de la lista
desplegable el usuario es transportado a esa página.
8. Proveer control del cursor para los formularios Web y otras pantallas, de manera que el cursor se
desplace al siguiente campo cuando se haya introducido el número correcto de caracteres. Un ejemplo
sería cuando un usuario introduce un código de área para un teléfono de EE.UU. y, después de introducir los
tres caracteres, el cursor cambia al campo del número telefónico local. Otro ejemplo es cuando se introducen
códigos de claves de registro. A menudo los códigos están en grupos de cuatro o cinco letras y, cuando se
llena el primer campo, el cursor avanza al siguiente campo, y así en lo sucesivo. El analista debe examinar
cada campo para ver si es conveniente usar el control del cursor automático.
Cualquier combinación de estas ocho metodologías puede ayudar al analista a reducir el número de pulsa-
ciones de tecla requeridas por el usuario, con lo cual se agiliza la entrada de datos y se minimizan los errores.
FIGURA 14.15
Ejemplo de menús desplegables
anidados con teclas de método
abreviado de Microsoft Visio
Professional.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 461
Operación y consistencia estándar
El sistema debe ser consistente a través de todas sus pantallas y todos sus mecanismos para operarlas en dis-
tintas aplicaciones. La consistencia facilita a los usuarios el proceso de aprender a usar las nuevas porciones
del sistema una vez que estén familiarizados con un componente. Podemos lograr la consistencia mediante los
siguientes puntos:
1. Ubicar los títulos, la fecha, hora y los mensajes del operador y de retroalimentación en los mismos lugares
en todas las pantallas.
2. Salir de cada programa mediante el uso de la misma clave u opción del menú.
3. Cancelar una transacción de manera consistente, como usar la tecla esc.
4. Obtener ayuda de una manera estandarizada, como usar una tecla de función.
5. Estandarizar los colores utilizados para todas las pantallas o páginas Web.
6. Estandarizar el uso de iconos para las operaciones similares al usar una interfaz gráfica de usuario.
7. Usar una terminología consistente en una pantalla de visualización o sitio Web.
8. Proveer una manera consistente de navegar por el diálogo.
9. Mantener la consistencia en la alineación de las fuentes, el tamaño y el color en las páginas Web.
RETROALIMENTACIÓN PARA LOS USUARIOS
Todos los sistemas requieren de retroalimentación para supervisar y modificar el comportamiento. Por lo ge-
neral, la retroalimentación compara el comportamiento actual con los objetivos predeterminados y devuelve la
información que describe el vacío entre el desempeño actual y el esperado.
Como los humanos en sí son sistemas complejos, requieren retroalimentación de otros para satisfacer las ne-
cesidades psicológicas y cognoscitivas que vimos antes en el capítulo. La retroalimentación también incrementa
la confianza humana. El grado de retroalimentación requerido es una característica individual.
Cuando los usuarios interactúan con las máquinas, de todas formas necesitan retroalimentación sobre el pro-
greso de su trabajo. Como diseñadores de interfaces de usuario, los analistas de sistemas deben estar conscientes
de la necesidad humana de retroalimentación para integrarla en el sistema. Además de los mensajes de texto, se
pueden utilizar iconos con frecuencia. Por ejemplo, al mostrar un reloj de arena mientras el sistema procesa in-
formación animamos al usuario a que espere un poco en vez de que oprima teclas en forma repetida para obtener
una respuesta.
La retroalimentación proveniente del sistema es necesaria para el usuario en siete situaciones distintas. La re-
troalimentación inoportuna o demasiado abundante no es útil, ya que los humanos poseen una capacidad limitada
de notificar al usuario que el sitio está respondiendo y que la entrada es correcta o necesita más información.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 5
En espera de ser alimentado
“Sí, es cierto que vendimos un paquete. Éste de aquí. No me
malentienda: sí hace el trabajo, sólo que no sabemos cuándo”.
Usted se encuentra hablando con Owen Itt, quien le está con-
tando sobre la reciente compra que hizo la unidad de ventas de
nuevo software para sus PC en red, el cual permite introducir los
datos de venta para cada uno de sus 16 vendedores, provee como
salida datos de comparación para ellos y proyecta las ventas a fu-
turo con base en los registros de las ventas anteriores.
“Pero hemos tenido algunas experiencias raras con este pro-
grama”. Owen continúa: “Parece lento o algo así. Por ejemplo,
nunca estamos seguros de cuándo termina. Yo escribo un comando
para obtener un archivo y no ocurre nada. Cerca de medio minuto
más tarde, si tengo suerte, podría aparecer la pantalla que quiero,
pero nunca puede uno estar seguro. Si le pido que guarde los datos
de las ventas, sólo comienza a zumbar. Si funciona, me regresa a
donde me encontraba antes; si no guarda los datos, de todas formas
me devuelve al punto anterior. Es confuso y nunca sé lo que debo
hacer. No hay nada en la pantalla de visualización que me diga lo
que debo hacer a continuación. ¿Ve el pequeño manual que se in-
cluyó con el sistema? Tiene las esquinas dobladas porque lo tuvi-
mos que hojear varias veces para tratar de averiguar qué debíamos
hacer después. También podemos conectarnos a Internet para bus-
car ayuda en línea, pero su asistencia técnica es prácticamente
inexistente. Además se lleva mucho tiempo”.
Con base en lo que escuchó en la entrevista, aproveche la
oportunidad de complementar el software mediante el diseño de
algún tipo de retroalimentación en pantalla para Owen y su equipo
de ventas. La retroalimentación debe abarcar todas las preocupacio-
nes de Owen y seguir los lineamientos para proporcionar retroali-
mentación a los usuarios, además de los lineamientos para diseñar
buenas pantallas. Dibuje un prototipo de las pantallas que considere
necesarias para lidiar con los problemas que menciona Owen.www.xlibros.com

462 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Tipos de retroalimentación
ACUSAR LA ACEPTACIÓN DE LA ENTRADA La primera situación en la que los usuarios necesitan
retroalimentación es para saber si la computadora aceptó la entrada. Por ejemplo, cuando un usuario
introduce un nombre en una línea, la computadora provee retroalimentación al usuario al desplazar el cursor
un carácter a la vez cuando se introducen las letras correctamente. Un ejemplo Web sería una página Web
que muestra el mensaje “Se procesó su pago, Su número de confirmación es 1234567. Gracias por usar
nuestros servicios”.
RECONOCER QUE LA ENTRADA ESTÁ EN EL FORMATO CORRECTO Los usuarios necesitan retroalimentación
para saber que la entrada está en el formato correcto. Por ejemplo, un usuario introduce un comando y la
retroalimentación indica el mensaje “LISTO” mientras el programa progresa a un nuevo punto. Un mal ejemplo
de retroalimentación que indica al usuario que la entrada está en el formato correcto es el mensaje “ENTRADA
BIEN”, debido a que el mensaje ocupa espacio adicional, es ambiguo y no hace nada por animar al usuario a
que introduzca más datos. Al colocar un pedido en Web o realizar un pago, por lo general aparece una página de
confirmación para solicitar al usuario que revise la información y haga clic en un botón o imagen para confirmar
el pedido o pago.
NOTIFICAR QUE LA ENTRADA NO ESTÁ EN EL FORMATO CORRECTO La retroalimentación es necesaria para
advertir a los usuarios de que la entrada no está en el formato correcto. Cuando los datos son incorrectos, una
manera de informar al usuario es generar una ventana que describa brevemente el problema con la entrada y
explique cómo puede el usuario corregirlo, como se muestra en la figura 14.16.
Cabe mencionar que el mensaje correspondiente a un error al introducir la duración de la suscripción es
amable y conciso pero no enigmático, por lo que incluso hasta los usuarios inexpertos podrán entenderlo. La
duración de la suscripción para el boletín informativo en línea se introduce en forma incorrecta, pero la retroa-
limentación no hace mucho hincapié en el error del usuario, sino que le ofrece opciones (13, 26 o 52 semanas)
para que pueda corregirlo fácilmente. En una pantalla de GUI es común que la retroalimentación esté en forma
de un cuadro de mensaje con un botón Aceptar.
Los mensajes Web tienen varios formatos. Uno de los métodos es devolver una nueva página con el mensaje
a un lado del campo que contiene el error. La nueva página Web puede tener un vínculo para obtener ayuda adi-
cional. Este método funciona para todos los sitios Web; el servidor controla el proceso de detectar y dar formato
a la nueva página. Otro método utiliza JavaScript para detectar el error y mostrar un cuadro de mensaje en la
pantalla actual con detalles sobre el error específico. Una ventaja de este método es que no se tiene que enviar
la página Web al servidor, además de que es más sensible. Las desventajas son que, si se desactiva JavaScript,
no se detectará el error y sólo se mostrará un error a la vez. También debe haber una forma de detectar el error
Lista de suscripciones al boletín informativo en línea de SOA
Inicial primer nombre Inicial segundo nombre Apellido paterno
Número Calle Apartamento
Ciudad Estado Código postal
Duración de la suscripción en semanas
La duración de la suscripción que
introdujo no se ofrece actualmente. Por favor
seleccione 13, 26 o 52 semanas.
M HURST
68506
CHK
LINCOLN NE
14
3349 SOUTH STREET
C
Método de pago
FIGURA 14.16
La retroalimentación informa al
usuario que la entrada no estaba en
el formato correcto y muestra una
lista de opciones.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 463
en el servidor. Una segunda desventaja es que tal vez JavaScript no detecte los errores en los que hay que leer
tablas de la base de datos, como verificar un número de tarjeta de crédito. Esto se puede compensar mediante el
uso de Ajax para poder enviar el número al servidor y devolver un error a la página Web. Sin embargo, debemos
recordar que algunos usuarios desactivan de manera intencional el uso de JavaScript; por lo tanto, los analistas
necesitan seguir una variedad de tácticas al comunicar los errores.
Las páginas Web también pueden usar JavaScript para detectar varios errores y mostrar mensajes de texto en
la página. Hay que cuidar que los mensajes de error estén lo bastante remarcados como para que el usuario los
vea. Una línea de texto pequeña de color rojo podría pasar desapercibida. Se puede usar un cuadro de mensaje o
sonidos para alertar a los usuarios al ocurrir uno o más errores.
El analista debe decidir si se van a detectar e informar los errores cuando el usuario haga clic en el botón
Enviar o en un hipervínculo (a esto se le conoce como validación por lotes), o si se van a detectar los errores
uno a la vez, como cuando un usuario introduce un mes como 14 y desplaza el cursor a otro campo. El segundo
método es más riesgoso, ya que una mala codificación podría hacer que el navegador entre en un ciclo infinito y
el usuario tendrá que cerrarlo.
Hasta ahora hemos visto la retroalimentación visual en forma de texto o iconos, pero muchos sistemas
también cuentan con herramientas de retroalimentación de audio. Cuando un usuario introduce datos en
forma incorrecta, el sistema podría emitir un sonido en vez de proveer una ventana. Pero la retroalimentación
de audio por sí sola no es descriptiva, por lo que no es tan útil para los usuarios como las instrucciones en
pantalla. Use la retroalimentación de audio con moderación, tal vez para avisar de situaciones urgentes. El
mismo consejo se aplica también al diseño de sitios Web que se pueden ver en una oficina abierta, en donde
los sonidos se esparcen y las bocinas de escritorio de un compañero de trabajo están al alcance de los oídos
de otras personas.
EXPLICAR UN RETRASO EN EL PROCESAMIENTO Uno de los tipos más importantes de retroalimentación informa
al usuario que habrá un retraso en el procesamiento de su solicitud. Los retrasos mayores de 10 segundos
requieren retroalimentación, para que el usuario sepa que el sistema sigue funcionando.
La figura 14.17 muestra una pantalla que provee retroalimentación en una ventana para un usuario que acaba
de solicitar la impresión de la lista de suscripciones del boletín informativo electrónico. La pantalla muestra un
enunciado que asegura al usuario que la solicitud se está procesando, así como un anuncio en la esquina superior
derecha que instruye al usuario que “ESPERE” hasta que se haya ejecutado el comando actual. La pantalla tam-
bién provee la forma de detener la operación si es necesario.
Algunas veces durante los retrasos, mientras se instala nuevo software se ejecuta un pequeño tutorial sobre
la nueva aplicación, cuyo propósito es servir como distracción en vez de retroalimentación sobre la instalación.
A menudo se utiliza una lista de los archivos que se van a copiar y una barra de estado para tranquilizar al usuario
Lista de suscripciones al boletín informativo en línea de SOA
Inicial primer nombre Inicial segundo nombre Apellido paterno
Número treet
Ciudad State
Duración de la suscripción en semanas
ento
stal
M odo de pago
rinting is now in progress.
To halt printing just type P.
La impresión está en proceso.
Para detener la impresión, oprima P.
ESPERE
FIGURA 14.17
La retroalimentación indica al
usuario que habrá un retraso
durante la impresión.www.xlibros.com

464 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
y asegurarle que el sistema está funcionando en forma apropiada. Por lo general los navegadores Web muestran
las páginas Web que se están cargando y el tiempo restante.
Es imprescindible incluir retroalimentación al usar Ajax para actualizar los formularios Web. Como no se
carga una nueva página Web, el usuario tal vez no esté consciente de que se están recuperando datos del servidor
para modificar la página Web actual. Cuando cambia una lista desplegable, un mensaje tal como “Por favor es-
pere mientras se llena la lista.” informa al usuario sobre el cambio.
Es muy importante sincronizar la retroalimentación de este tipo. Una respuesta demasiado lenta del sistema
provocaría que el usuario introdujera comandos que impidan o interrumpan el procesamiento.
ACUSAR EL LLENADO DE UNA SOLICITUD Los usuarios necesitan saber cuándo se completa su solicitud para
poder introducir nuevas solicitudes. A menudo aparece un mensaje de retroalimentación específico cuando el
usuario completa una acción, como “Se agregó el registro del empleado”, “Se modificó el registro del cliente” o
“Se eliminó el artículo número 12345”.
NOTIFICAR QUE NO SE COMPLETÓ UNA SOLICITUD También se necesita la retroalimentación para hacer saber
al usuario que la computadora no puede completar una solicitud. Si la pantalla indica “No se pudo procesar
la solicitud. Revise la solicitud de nuevo”, el usuario puede entonces regresar para verificar si se introdujo la
solicitud en forma incorrecta, en vez de que siga introduciendo comandos que no se pueden ejecutar.
OFRECER AL USUARIO UNA RETROALIMENTACIÓN MÁS DETALLADA Los usuarios necesitan tener la seguridad
de que haya una retroalimentación más detallada disponible, y se les debe mostrar cómo pueden obtenerla. Se
pueden emplear comandos como Asistir, Instruir, Explicar y Más. El usuario también puede escribir un signo
de interrogación o hacer clic en un icono apropiado para obtener más retroalimentación. Se ha cuestionado el
uso del comando Ayuda como forma de obtener más información, ya que los usuarios se pueden sentir indefensos
o atrapados en una trampa de la que deben escapar. Pero como esta convención es la que está en uso y gracias a
que los usuarios están familiarizados con ella, el problema no es grave.
Al diseñar interfaces Web es posible incrustar hipervínculos para permitir al usuario saltar a las pantallas de
ayuda relevantes o ver más información. Por lo general, los hipervínculos se resaltan con subrayado, cursiva o un
color distinto. Pueden ser imágenes, texto o iconos.
Incluir retroalimentación en el diseño
Si se utiliza en forma correcta, la retroalimentación puede ser un poderoso refuerzo de los procesos de aprendi-
zaje de los usuarios, puede servir para mejorar el desempeño del usuario con el sistema, incrementar la motiva-
ción para producir y mejorar el ajuste entre el usuario, la tarea y la tecnología.
VARIAS OPCIONES DE AYUDA La retroalimentación en las computadoras personales se ha desarrollado a través
de los años. La “ayuda” empezó originalmente como una respuesta al usuario que oprimía una tecla de función
tal como F1; la alternativa de la GUI es el menú de ayuda desplegable. Esta metodología era incómoda, ya que
los usuarios finales tenían que navegar por una tabla de contenido o buscar a través de un índice. Después surgió
la ayuda sensible al contexto. Los usuarios sólo tenían que hacer clic en el botón derecho del ratón para revelar
los temas o explicaciones sobre la pantalla o área de la pantalla actual. Luego se produjo un tercer tipo de ayuda
en las computadoras personales, donde el usuario coloca la flecha sobre un icono y la deja ahí durante un par de
segundos. En este momento aparece en algunos programas un pequeño globo similar a los de las historietas. Este
globo explica un poco sobre la función del icono.
El cuarto tipo de ayuda es un asistente, el cual hace al usuario una serie de preguntas y después realiza la
acción correspondiente. Los asistentes ayudan a los usuarios a realizar los procesos complicados o desconocidos,
como establecer las conexiones de red o reservar el asiento de un avión en línea. La mayoría de los usuarios es-
tán familiarizados con los asistentes dado que se emplean para crear una presentación de PowerPoint o elegir un
estilo para un memo en el procesador de palabras.
Además de integrar la ayuda en una aplicación, con frecuencia los fabricantes de software ofrecen ayuda
en línea (ya sea automatizada o personalizada a través de un chat en vivo) o líneas de ayuda (sin embargo, la
mayoría de las líneas telefónicas de servicio al cliente no son gratuitas). Algunos fabricantes de software COTS
ofrecen un sistema de envío de fax. Un usuario puede solicitar que se le envíe por fax un catálogo de varios do-
cumentos de ayuda y después puede pedir del catálogo con sólo introducir el número del artículo mediante un
teléfono de tonos.
Por último, los usuarios pueden buscar y encontrar soporte de otros usuarios por medio de los foros de soft-
ware. Claro está que este tipo de soporte es no oficial, por lo que la información que se obtenga puede ser cierta,
parcialmente cierta o errónea. Los principios relacionados con el uso de los foros de software son los mismos
que se mencionan más adelante en el capítulo 16, en donde examinaremos el método FOLKLORE y los sistemas
de recomendaciones. Maneje con cautela y escepticismo todos los parches de software que se publican en los
tableros de anuncios, blogs, grupos de discusión o salas de chat.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 465
Además de la ayuda informal en el software, los sitios Web de los distribuidores son en extremo útiles para
actualizar controladores, visores y el software en sí. La mayoría de las publicaciones de cómputo en línea tienen
cierto tipo de “vigilancia de controladores” o “informe de errores” que vigila los tableros de anuncios y los sitios
Web en busca de programas útiles que se puedan descargar. Los programas buscarán en los sitios Web de los dis-
tribuidores las actualizaciones más recientes, informarán a los usuarios sobre éstas, ayudarán con las descargas y
en efecto actualizarán las aplicaciones del usuario.
CONSIDERACIONES DE DISEÑO ESPECIALES PARA EL COMERCIO ELECTRÓNICO
Muchos de los principios de diseño de interfaces de usuario que aprendió en este libro en relación con la retroalimen-
tación también se extienden al diseño de sitios Web de comercio electrónico. En esta sección veremos unas cuantas
consideraciones adicionales que pueden brindar a sus diseños de interfaces Web una funcionalidad mejorada.
Solicitar retroalimentación de los clientes del sitio Web de comercio electrónico
No sólo hay que brindar a los usuarios retroalimentación sobre lo que ocurre con un pedido, sino que también
debemos obtener retroalimentación de ellos. La mayoría de los sitios Web de comercio electrónico tienen un bo-
tón Retroalimentación (Feedback). Hay dos maneras estándar de diseñar lo que los usuarios experimentarán al
hacer clic en el botón Retroalimentación.
La primera es iniciar el programa de correo electrónico del usuario con la dirección de correo electrónico del con-
tacto de la empresa incluida automáticamente en el campo Para:. Este método evita los errores de escritura y facilita
el proceso de contactar a la organización. El usuario no tiene que salir del sitio para comunicarse con la empresa. Sin
embargo, estos mensajes generan la expectativa de que se van a responder de la misma forma que el correo ordina-
rio o las llamadas telefónicas. Las investigaciones indican que el 60 por ciento de las organizaciones con este tipo de
herramienta de contacto vía correo electrónico en sus sitios no tienen a nadie asignado para contestar a los mensajes
de correo electrónico recibidos. Por ende, la empresa está perdiendo una valiosa retroalimentación, al tiempo que los
clientes se hacen a la idea de que se están comunicando y se irritan cuando no reciben ninguna respuesta. Si usted di-
seña este tipo de oportunidad de retroalimentación, también necesita diseñar los procedimientos para que la organiza-
ción responda al correo electrónico del sitio Web. Algunos diseñadores manejan este problema mediante la creación de
sistemas para devolver de manera automática la respuesta a un correo electrónico, lo cual genera un número de caso
o de incidente único, ofrece instrucciones adicionales sobre cómo proceder (hipervínculos a páginas FAQ, tal vez) u
ofrece números telefónicos de líneas de ayuda que no están disponibles para el público en general.
El segundo tipo de diseño para cosechar la retroalimentación de los usuarios cuando se utiliza un sitio Web
de comercio electrónico es llevarlos a una plantilla de mensajes en blanco cuando hagan clic en Retroalimenta-
ción. Algunas herramientas de creación de sitios Web nos permiten crear e insertar con facilidad un formulario
de retroalimentación en nuestro sitio. Este formulario podría empezar con un encabezado que diga “Retroalimen-
tación de la empresa X” y después “Puede usar el siguiente formulario para enviar sugerencias, comentarios y
preguntas sobre el sitio X a nuestro equipo de Servicio al cliente”.
Los campos pueden incluir Primer nombre, Apellido paterno, Dirección de correo electrónico, Asunto (un
campo que provee un menú desplegable con las selecciones de productos o servicios de la empresa y pide al
usuario que “Por favor seleccione una opción”), una sección “Escriba aquí su mensaje:” (un espacio libre en el
formulario en donde los usuarios pueden escribir su mensaje) y los botones estándar Enviar y Borrar al final
del formulario. Este tipo de formulario permite al analista asegurar que los datos del usuario ya tengan el for-
mato correcto para almacenarlos en una base de datos. En consecuencia, los datos introducidos en el formulario
de retroalimentación son más fáciles de analizar teniendo todo en cuenta.
Por ende, el analista hace algo más que sólo diseñar una respuesta a un correo electrónico individual. El
analista ayuda a la organización a capturar, almacenar, procesar y analizar la valiosa información de los clientes
de una manera que sea más probable que la empresa pueda detectar las tendencias importantes en la respuesta al
cliente, en vez de sólo reaccionar a las consultas individuales.
Fácil navegación para los sitios Web de comercio electrónico
Muchos autores hablan de lo que se conoce como “navegación intuitiva” para los sitios Web de comercio elec-
trónico. Los usuarios necesitan saber cómo navegar en el sitio sin tener que aprender a usar una nueva interfaz o
explorar cada centímetro del sitio Web para poder encontrar lo que desean. El estándar para este tipo de metodo-
logía de navegación se conoce como navegación de un solo clic.
Hay cuatro maneras de diseñar una navegación sencilla de un solo clic para un sitio de comercio electrónico:
1) crear un menú con rollover, 2) crear una colección de vínculos jerárquicos de manera que la página de inicio
se convierta en una descripción de los encabezados de los temas clave asociados con el sitio Web, 3) colocar un
mapa del sitio en la página de inicio y enfatizar el vínculo a éste (también se debe colocar en todas las demás
páginas del sitio) y 4) colocar una barra de navegación en cada página interna (por lo general en la parte superior
o izquierda de la página) que repita las categorías utilizadas en la pantalla de entrada.www.xlibros.com

466 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
MENÚS CON ROLLOVER Es posible crear un menú (o botón) con rollover mediante hojas de estilo en cascada con
JavaScript y divisiones de HTML. El menú con rollover aparece cuando el cliente que usa el sitio Web desplaza
el cursor sobre un vínculo.
VÍNCULOS JERÁRQUICOS Crear una descripción del contenido del sitio por medio de la presentación de una
tabla de contenido en la página de inicio es otra manera de agilizar la navegación del sitio. Sin embargo,
este diseño impone varias restricciones sobre la creatividad del diseñador, y algunas veces el solo hecho
de presentar una lista de temas no transmite al usuario de manera adecuada la misión estratégica de la
organización.
MAPA DEL SITIO Diseñar y después mostrar de manera prominente el vínculo a un mapa del sitio es una tercera
forma de mejorar la eficiencia en la navegación. Recuerde incluir el vínculo al mapa del sitio en la página de
inicio y en todas las demás páginas también.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 6
Al correr en un maratón, es conveniente saber hacia dónde se dirige
Marathon Vitamin Shops tuvo éxito al lanzar su sitio Web. Los
desarrolladores Web pusieron todo el catálogo completo en línea e
incluyeron una variedad de máscaras (o personas, como se les co-
noce en el navegador Firefox) para que todos los tipos de clientes
disfrutaran el sitio Web (vea Oportunidades de consultoría 1.1 y
12.3 para obtener más detalles).
Los analistas se van a reunir con el propietario Bill Berry y
algunos empleados para evaluar la retroalimentación de los clientes
así como dar a conocer sus propias reacciones al nuevo sitio Web.
La reunión se realizará en una sala de conferencias extensa, donde
tienen una computadora con acceso a Internet y un proyector. Mien-
tras se sientan a la mesa, se proyecta la pantalla de entrada para el
sitio Web en la parte frontal de la sala. “El sitio Web atrajo mucha
atención, pero queremos dar a los clientes incluso más para que si-
gan volviendo”, dice Bill, señalando la pantalla.
Bill continúa: “No es que vayamos a cerrar nuestras tiendas ni
nada por el estilo. De hecho, es justo lo contrario. Cuando los clien-
tes se enteran de que estamos en la Web, están impacientes por lo-
calizar la tienda en su comunidad. Desean poder entrar en una
tienda y hablar con un experto capacitado en vez de comprar todo
por Internet. Necesitamos decirle a la gente cómo llegar ahí.”.
“Creemos que podemos mejorar el sitio al agregar mejoras y
características especiales”, dice Al Falfa, miembro del equipo de
sistemas que diseñó e implementó originalmente el sitio Web de co-
mercio electrónico.
“Sí”, dice Ginger Rute, uno de los otros miembros del equipo
de desarrollo de sistemas, mientras asiente con la cabeza. “La uni-
versidad usa una herramienta de creación de mapas de MapQuest y
Home Depot usa mapas de Microsoft”.
Vita Ming, otro miembro del equipo original de desarrollo de
sistemas, dice con entusiasmo: “Sabemos de un par de buenos ser-
vicios de tableros de mensajes y salas de chat que podemos integrar
en nuestro sitio Web. Creemos que pueden mejorar la pegajosidad
del sitio; las personas permanecerán más tiempo en el sitio y tam-
bién querrán regresar”.
“Es una excelente idea”, dice Jin Singh, uno de los empleados
con conocimiento técnico de Marathon. “Podemos dejar que los
clientes hablen entre sí y se cuenten sobre algún producto que les
gustó, por ejemplo. Podríamos incluso dejar que inicien sus pro-
pios blogs.
Vita continúa mientras se mueve hacia el teclado de su compu-
tadora y dice: “Déjame enseñarte algunos buenos sitios”. Mientras
escribe el primer URL, el grupo ve el sitio proyectado. “Utilizan
sistemas de chat de iChat y Multicity.com”, continúa.
“Los clientes también necesitan buscar más información sobre
un producto o fabricante”, agrega Al. “Vamos a facilitarles este
proceso. Veamos www.cincinnati.com como un ejemplo. Ellos uti-
lizan Google para buscar la información”.
Después de escuchar atentamente, Bill habla: “La información
médica también podría ser útil”, dice. He observado que www.me-
dpool.com tiene noticias médicas de acquiremedia. En el gimnasio
al que voy he visto personas en las caminadoras observando los
canales financieros mientras hacen ejercicio”.
“Ya que estamos en eso, ¿por qué no agregamos noticias e
información financiera al sitio Web?”, pregunta Ginger. “He visto
que una empresa llamada Moreover.com aparece con frecuencia
como proveedor”.
Piense en la conversación entre el equipo de desarrollo de
sistemas y las personas de las tiendas Maraton Vitamin Shops. Al-
gunas de las sugerencias para mejorar implican aprovechar los
servicios gratuitos; otros requieren pagos que varían de $1,000 a
$5,000 al año. Aunque algunas eran buenas ideas, tal vez otras no
sean prácticas o viables. Quizás algunas de las ideas simplemente
no tengan sentido para la empresa.
Para cada uno de los siguientes puntos, revise lo que sabe
acerca de la misión y las actividades de negocios de Marathon Vi-
tamin Shops. Después haga una recomendación en relación con
cada una de las opciones que han elegido los analistas y clientes, y
defiéndala:
Aplicación web híbrida (mashup) con Google Maps.
Salas de chat y tableros de mensajes.
Blogs.
Motores de búsqueda.
Información médica.
Fuentes de noticias e información de los mercados
financieros.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 467
BARRA DE NAVEGACIÓN Por último, puede diseñar barras de navegación que se muestren de manera consistente
en la página de inicio, así como en la parte superior y en la parte izquierda de todas las demás páginas que
conforman el sitio. Una vez establecidas (durante la fase de requerimientos de información) las categorías más
útiles y más usadas (por lo general categorías como “Nuestra empresa”, “Nuestros productos”, “Compre ahora”,
“Contacto”, “Mapa del sitio” y “Buscar”), recuerde incluirlas en todas las páginas.
OTRAS OPCIONES DE NAVEGACIÓN Incluir una función de búsqueda es otra opción. Incluya el agregar un motor
de búsqueda tal como Google a su sitio. Las funciones simples de búsqueda funcionan bien para sitios pequeños
y manejables, pero a medida que éstos crecen, se requieren funciones de búsqueda avanzadas que incluyen lógica
booleana (que veremos más adelante en este capítulo).
También es importante crear flexibilidad en la forma en que los usuarios navegan por la Web. Un diseña-
dor experto de sitios Web trataría de incorporar muchas formas de buscar información sobre un tema especí-
fico. En la figura 14.18 se muestra una página Web de DinoTech. Por ejemplo, un usuario interesado en una
carrera profesional internacional de TI puede buscar información del sitio Web de DinoTech de tres maneras
A T R A C T I V O D E L A M A C
Los megamotores de búsqueda —que obtienen resultados de varios motores de búsqueda, agrupan los resultados y
los muestran de una manera más útil que cualquier motor de búsqueda individual— han existido desde hace buen
tiempo. Hay una aplicación única en la plataforma Mac que va un paso más allá.
Esa aplicación es DEVONagent, un paquete de software que utiliza motores de búsqueda generales y especiali-
zados para obtener resultados, y después ofrece al usuario la opción de ver esos resultados en un mapa de temas
gráfico. Otra opción es ver los resultados en una lista clasificada por relevancia.
Los analistas encontrarán que DEVONagent es útil si comprenden y hacen uso del mapa de temas gráfico. También
es útil si se requieren búsquedas complejas (es decir, si las búsquedas estándar no profundizan lo suficiente para encon-
trar la información exacta que se necesita). Y también se puede usar en las búsquedas que se necesitan repetir con fre-
cuencia.
FIGURA 14.MAC
DEVONagent de DEVONtechnologies.www.xlibros.com

468 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
distintas. Si les interesa trabajar en Argentina, pueden trabajar en la bandera de Argentina, hacer clic en el
nombre del país o en el mapa que representa a Argentina.
Es conveniente diseñar un sitio Web con navegación para los usuarios con distinto procesamiento cognosci-
tivo o con distintos intereses. Es incluso posible que el mismo usuario pueda usar los tres métodos antes mencio-
nados en distintos momentos. Todo ello aumenta la usabilidad de un sitio Web.
Sin embargo, la principal prioridad en la navegación es que, sin importar lo que haga, debe facilitar lo más
que pueda a los usuarios el proceso de regresar a una página anterior y que también puedan regresar con relativa
facilidad al lugar en donde entraron al sitio de su cliente. Su principal preocupación es mantener a los consumi-
dores en el sitio Web. Entre más tiempo estén en el sitio, mayor será la probabilidad de que compren algo. Por
lo tanto se debe asegurar que, si los usuarios navegan a un vínculo en el sitio Web de su cliente, puedan hallar su
camino de vuelta. Al hacer estas cosas asegurará la pegajosidad del sitio Web. No es conveniente crear barreras
para el consumidor que desea regresar al sitio Web de su cliente.
APLICACIONES WEB HÍBRIDAS (MASHUPS)
Una interfaz de programación de aplicaciones (API) es un conjunto de pequeños programas y protocolos que se
utilizan como bloques de construcción para la creación de aplicaciones de software. Cuando dos o más API
se utilizan en conjunto, forman una aplicación híbrida; muchas son de código fuente abierto, por lo que los de-
sarrolladores pueden usar una API de un sitio como Google Maps y combinarla con una API que contenga otros
datos para producir una aplicación web completamente nueva.
Por ejemplo, Music Anchor permite buscar música por género, título o autor, desplegar listas de artistas por
género y canciones por artistas, para reproducir los videos correspondientes. Esta aplicación web híbrida logra
todo esto combinando API de Last.fm, MusicBrainz, Amazon, eBay y YouTube.
Tal vez una empresa grande con muchos puntos de venta de menudeo en una región quiera facilitar a sus
clientes el proceso de encontrar sus tiendas. Podría ser conveniente que contrataran una empresa como Blipstar,
que provee un servicio para permitir que las empresas publiquen información sobre sus tiendas de menudeo.
Blipstar las geocodifica y las coloca en un mapa de Google. Después la empresa coloca un vínculo a esta infor-
mación en su propio sitio Web, de manera que los clientes sólo tienen que introducir su código postal y dejar que
la aplicación híbrida muestre la ubicación de la tienda de menudeo más cercana.
Estas aplicaciones se están convirtiendo en una nueva forma de presentar información. Es muy probable que
aparezcan pronto muchas aplicaciones web híbridas muy útiles. Puede buscarlas en www.programmableweb.com.
DISEÑO DE CONSULTAS
Cuando los usuarios hacen preguntas o se comunican con la base de datos, se dice que la consultan. Hay seis
tipos distintos de consultas que son las más comunes. Si usted pone mucha atención al diseño de las consultas,
FIGURA 14.18
Un ejemplo de una página Web
que permite a los usuarios navegar
a la página deseada en tres
formas.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 469
podrá ayudar a reducir el tiempo que invierten los usuarios en consultar la base de datos, los ayudará a encontrar
los datos que desean y obtendrán una experiencia más cómoda en general.
Tipos de consultas
Las preguntas que planteamos con respecto a los datos de nuestra base de datos se conocen como consultas. Hay
seis tipos básicos de consultas. Cada consulta involucra a tres elementos: una entidad, un atributo y un valor. En
cada caso se proporcionan dos de estos elementos y la intención de la consulta es encontrar el elemento restante.
Usaremos la figura 14.19 para ilustrar todos los ejemplos de las consultas.
TIPO DE CONSULTA 1 Se proporciona la entidad y uno de los atributos de ésta. El propósito de la consulta es
encontrar el valor. La consulta se puede expresar de la siguiente manera:
¿Cuál es el valor de un atributo especificado para una entidad específica?
Algunas veces es más conveniente usar la notación para formular la consulta. Esta consulta se puede escribir así:
V d (E, A)
donde V representa el valor, E la entidad y A el atributo; se proporcionan las variables entre paréntesis.
La pregunta
¿Cuánto ganó el empleado número 73712 en el año 2009?
se puede declarar de manera más específica como
¿Cuál es el valor del atributo ANIO-2009 para la entidad NUMERO EMPLEADO 73712?
Se encontrará el registro que contiene al empleado número 73712 y la respuesta a la consulta será $47,100.
TIPO DE CONSULTA 2 La intención del segundo tipo de consulta es encontrar una entidad o unas entidades cuando
se proporciona un atributo y un valor. El tipo de consulta 2 se puede establecer de la siguiente manera:
¿Qué entidad tiene un valor específico para un atributo en particular?
Como los valores también pueden ser numéricos, es posible buscar un valor igual a, mayor que, menor que, no
igual a, mayor o igual a, y así en lo sucesivo. El siguiente es un ejemplo de este tipo de consulta:
¿Qué empleado(s) obtuvo más de $50,000 en 2009?
La notación para el tipo de consulta 2 es
E d (V, A)
NOMBRE
EMPLEADO DEPARTAMENTO E/R ANIO-2006 ANIO-2007 ANIO-2008 ANIO-2009
NUMERO
EMPLEADO
HISTORIAL-INGRESOS
72845 Waters Ventas externas S 48,960 51,400 49,050 52,900
72888 Dryne Ventas externas S 42,200 44,700 48,020 50,580
73712 Fawcett Distribución H 43,500 45,500 46,780 47,100
80345 Well, Jr. Marketing S 65,000 71,000 75,000 78,000
84672 Piper Mantenimiento H 40,560 42,340 43,520 44,910
89760 Acquia Contabilidad H 38,755 40,040 41,380 42,540
Los años
son los
atributos.
Los salarios son
los valores.
Los números de
empleados son
las entidades.
FIGURA 14.19
Es posible realizar seis tipos
básicos de consultas en una tabla
que contiene entidades, atributos
y valores.www.xlibros.com

470 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
En este caso tres empleados ganaron más de $50,000, por lo que la respuesta será un listado de estos tres números
de empleado: 72845, 72888 y 80345.
TIPO DE CONSULTA 3 El propósito de este tipo de consulta es determinar qué atributos se ajustan a la descripción
provista cuando se proporcionan la entidad y el valor. El tipo de consulta 3 se puede establecer de la siguiente
manera:
¿Qué atributo(s) tiene un valor especificado para una entidad en particular?
Esta consulta es útil cuando muchos atributos similares tienen la misma propiedad. El siguiente ejemplo tiene
atributos similares (años específicos) que contienen los salarios anuales para los empleados de la empresa:
¿En qué años ganó el empleado número 72845 más de $50,000?
o, dicho en forma más precisa,
¿Qué atributos {ANIO-2006, ANIO-2007, ANIO-2008, ANIO-2009} tienen un valor [gt] 50,000 para la
entidad NUMERO-EMPLEADO = 72485?
en donde la lista opcional entre llaves ({ }) es el conjunto de atributos elegibles.
La notación para el tipo de consulta 3 es
A d (V, E)
En este ejemplo, Waters (número de empleado 72845) hizo más de $50,000 durante dos años. Por lo tanto, la res-
puesta será el año 2007 y el año 2009. El tipo de consulta 3 es más raro que los dos tipos anteriores debido a que
requiere tener atributos similares que exhiban las mismas propiedades.
TIPO DE CONSULTA 4 El tipo de consulta 4 es similar al tipo de consulta 1. La diferencia es que se desean los
valores de todos los atributos. La consulta 4 se puede expresar de la siguiente manera:
Liste todos los valores para todos los atributos de una entidad específica.
Un ejemplo del tipo de consulta 4 es:
Liste todos los detalles en el archivo del historial de ingresos para el empleado número 72888.
La notación para el tipo de consulta 4 es
todos los V d (E, todos los A)
La respuesta para esta consulta será todo el registro completo para el empleado llamado Dryne (número de em-
pleado 72888).
TIPO DE CONSULTA 5 El quinto tipo de consulta es otra consulta global, pero es similar en forma al tipo de
consulta 2. Podemos establecerlo de la siguiente manera:
Liste todas las entidades que tengan un valor específico para todos los atributos.
El siguiente es un ejemplo del tipo de consulta 5:
Liste a todos los empleados cuyos ingresos sean superiores a $50,000 en cualquiera de los años disponibles.
La notación para el tipo de consulta 5 es
todas los E d (V, todos los A)
La respuesta a esta consulta será 72845, 72888 y 80345.
TIPO DE CONSULTA 6 El sexto tipo de consulta es similar al tipo de consulta 3. La diferencia es que el tipo
de consulta 6 solicita un listado de los atributos para todas las entidades, en vez de hacerlo para una entidad
específica. Podemos establecer el tipo de consulta 6 de la siguiente manera:
Liste todos los atributos que tengan un valor especificado para todas las entidades.
El siguiente es un ejemplo del tipo de consulta 6:
Liste todos los años en que los ingresos hayan sido superiores a $40,000 para todos los empelados de la
empresa.
La notación para el tipo de consulta 6 es
todos los A d (V, todas las E)www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 471
La respuesta será ANIO-2007, ANIO-2008 y ANIO-2009. Al igual que con el tipo de consulta 3, el tipo de
consulta 6 no se utiliza tanto como los demás tipos.
CREACIÓN DE CONSULTAS MÁS COMPLEJAS Los seis tipos anteriores de consultas son sólo bloques de
construcción para consultas más complejas. Se pueden formar expresiones, conocidas como expresiones
booleanas, para las consultas. Un ejemplo de una expresión booleana es:
Liste todos los empleados que tengan códigos postales mayores o iguales a 60001 y menores que 70000, y
que hayan pedido más de $500 de nuestros catálogos o hayan hecho por lo menos cinco pedidos en el
último año.
Una dificultad con este enunciado es determinar qué operador (por ejemplo, AND [Y]) pertenece a cuál con-
dición; también es difícil determinar la secuencia en la que se deben llevar a cabo las partes de la expresión. Lo
siguiente puede ser de utilidad para aclarar este problema:
LISTE A TODOS LOS CLIENTES QUE TENGAN (CODIGO-POSTAL GE 60001 AND CODIGO-
POSTAL LT 70000) AND (MONTO-PEDIDO GT 500 OR NUMERO-PEDIDOS GE 5)
Ahora se elimina parte de la confusión. La primera mejora es que los operadores se expresan con más cla-
ridad como GE (mayor o igual que), GT (menor que) y LT (menor que) en vez de usar frases en español, como
“al menos”. En segundo lugar, los atributos reciben distintos nombres, como MONTO-PEDIDO y NUMERO-
PEDIDOS. En el primer enunciado se hizo referencia a estos atributos como “hayan pedido” y “hayan hecho”.
Por último, se utilizan paréntesis para indicar el orden en el que se va a realizar la lógica. Lo que esté entre pa-
réntesis se realiza primero.
Por lo general las operaciones se realizan en un orden predeterminado de precedencia. Generalmente las
operaciones aritméticas se realizan primero (exponenciación, después multiplicación o división y luego suma o
resta). A continuación se realizan las operaciones de comparación. Estas operaciones son GT (mayor que), LT
(menor que), etcétera. Por último se realizan las operaciones booleanas (primero AND [Y] y después OR [O]).
Dentro del mismo nivel el orden va generalmente de izquierda a derecha. La precedencia se sintetiza en la fi-
gura 14.20.
Métodos de consulta
Dos métodos de consulta populares son las consultas mediante ejemplos y el lenguaje de consulta estructurado.
CONSULTA MEDIANTE EJEMPLOS La consulta mediante ejemplo (QBE) es un método simple pero potente para
implementar consultas en los sistemas de bases de datos, como Microsoft Access. Los campos de la base de
datos se seleccionan y muestran en una cuadrícula, y los valores solicitados en la consulta se introducen en el
área del campo o debajo de éste. La consulta debe ser capaz de seleccionar ambas filas de la tabla que coincidan
con las condiciones, así como las columnas específicas (campos). Es posible establecer condiciones complejas
para seleccionar registros y el usuario puede especificar con facilidad las columnas que desea ordenar. La figura
14.21 es un ejemplo de una consulta mediante el uso de Microsoft Access. La pantalla de diseño de la consulta se
divide en dos porciones. La porción superior contiene las tablas seleccionadas para la consulta y sus relaciones,
y la porción inferior contiene la cuadrícula de selección de la consulta. Los campos de las tablas de la base de
datos se arrastran a la cuadrícula.
Las primeras dos filas contienen el campo y la tabla en donde se encuentra ese campo. La siguiente fila
contiene información sobre el orden. En este ejemplo los resultados se ordenarán por NOMBRE CLIENTE
(CUSTOMER NAME). Una marca de verificación en el cuadro Mostrar (Show) (cuarta fila hacia abajo) indica
que el campo se debe mostrar en los resultados. Cabe mencionar que se seleccionan los elementos NUMERO
Tipo
Operadores aritméticos 1 * *
2 * /
3 + –
Operadores de comparación 4 GT LT
EQ NE
GE LE
Operadores booleanos 5 AND
6 OR
Nivel Símbolo FIGURA 14.20
Los operadores aritméticos, de
comparación y booleanos se
procesan en un orden jerárquico
de precedencia, a menos que se
utilicen paréntesis.www.xlibros.com

472 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
CLIENTE (CUSTOMER NUMBER), NOMBRE CLIENTE (CUSTOMER NAME) y SIG-
NIFICADO CODIGO ESTADO (STATUS CODE MEANING) para la pantalla resultante
(también se muestran otros campos, pero no aparecen en la pantalla). Observe que CODIGO
ESTADO CUENTA (ACCOUNT STATUS CODE) y CODIGO TIPO CUENTA (ACCOUNT
TYPE CODE) no están marcados y por lo tanto no estarán en los resultados finales. En las filas
de criterios hay un 1 en el CODIGO ESTADO CUENTA (para indicar un registro activo); ade-
más hay una C y una D (para seleccionar un Cliente general o un Cliente de descuento) en las
columnas CODIGO TIPO CUENTA. Dos condiciones en la misma fila indican una condición
O P O R T U N I D A D D E C O N S U L T O R Í A 1 4 . 7
¡Eh, mírame! (Repetición)
Usted acaba de recibir una llamada para que dé otro vistazo al
sistema de Merman’s Costume Rentals. He aquí parte de la base de
datos creada para Annie Oaklea de Merman’s (con quien trabajó en
las Oportunidades de consultoría 7.1 y 8.1). La base de datos con-
tiene información como el costo de la renta, la fecha en que salió,
la fecha de entrega y el número de días que se ha rentado el disfraz
desde el inicio del año (DIAS RENTA AAF) (vea la figura 14.C1).
Después de analizar un día común de Annie en el negocio de
renta de disfraces, usted descubre que hay varias solicitudes que ella
debe obtener de la base de datos para poder tomar decisiones sobre
cuándo reemplazar los disfraces de uso frecuente, o incluso cuándo
comprar más disfraces de un tipo específico. Ella también necesita
recordar que, por ejemplo, debe seguir agradando a los clientes para
quienes no tuvo disponible algún disfraz, o cuándo llamar a los
clientes cuyo plazo de entrega del disfraz se haya vencido, etcétera.
Formule varias consultas que le ayuden a obtener la informa-
ción que necesita de la base de datos. (Sugerencia: Haga todas las
suposiciones necesarias sobre los tipos de información que necesita
para tomar las decisiones y use todos los tipos de consultas que
pueda de los que vimos en este capítulo). Describa en un párrafo
qué tan distintas serían las consultas de Annie si trabajara con un
sistema basado en Web o con hipervínculos.
SOLICITUDES
RECHAZADAS
TIPO DE
DISFRAZ
DIAS
RENTA
AAF
FECHA
VENCI-
MIENTOCOSTO
NUMERO
DISFRAZ
NUMERO
TRAJE
RENTA-DISFRACES
0003 Lady MacBeth F, SM 01 Azul 15.00 10/15 11/30 150 Estándar 2
1342 Bear F, MED 01 Café obscuro 12.50 10/24 11/09 26 Estándar 0
1344 Bear F, MED 02 Café obscuro 12.50 10/24 11/09 115 Estándar 0
1347 Bear F, LG 01 Negro 12.50 10/24 11/09 22 Estándar 0
1348 Bear F, LG 02 Negro 12.50 11/01 11/08 10 Estándar 0
1400 Goldilocks F, MED 01 Azul claro 7.00 10/24 11/09 140 Estándar 0
1402 Goldilocks F, MED 02 Azul claro 7.00 10/28 11/09 10 Estándar 0
1852 Hamlet M, MED 01 Verde obscuro 15.00 11/02 11/23 115 Estándar 3
1853 Ophelia F, SM 01 Azul claro 15.00 11/02 11/23 22 Estándar 0
4715 Prince M, LG 01 Blanco/morado 10.00 11/04 11/21 145 Estándar 5
4730 Frog M, SM 01 Verde 7.00 11/04 11/21 175 Estándar 2
7822 Jester M, MED 01 Multi 7.50 11/10 12/08 12 Estándar 0
7824 Jester M, MED 02 Multi 7.50 11/09 11/15 10 Estándar 0
7823 Executioner M, LG 01 Negro 7.00 11/19 12/05 21 Estándar 0
8645 Mr. Spock N, LG 01 Naranja 18.00 09/07 09/12 150 Moderno 4
9000 Pantomime F, LG 01 Rojo 7.00 08/25 09/15 56 Estándar 0
9001 Pantomime M, MED 01 Azul 7.00 08/25 09/15 72 Estándar 0
9121 Juggler M, MED 01 Multi 7.00 11/05 11/19 14 Estándar
Estándar
0
9156 Napoleon M, SM 01 Azul/blanco 15.00 10/26 11/23 56 1
COLOR
FECHA
SALIDADESCRIPCION
FIGURA 14.C1
Una porción de la base de datos de la tienda Merman’s Costume Rental.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 473
AND, y dos condiciones en distintas filas representan una condición OR. Esta consulta especifica que el usuario
debe seleccionar un Cliente activo (Active Customer) y un Cliente general (General Client) o de descuento (Dis-
count Customer).
Los resultados de una consulta se muestran en una tabla como en la figura 14.22. Cabe mencionar que
no aparecen CODIGO ESTADO CUENTA (ACCOUNT STATUS CODE) ni CODIGO TIPO CUENTA (AC-
COUNT TYPE CODE). No están marcados y se incluyen en la consulta sólo para fines de selección. Como al-
ternativa se muestran los significados del código, que son más útiles para el usuario. Los nombres de los clientes
están en secuencia por orden alfabético.
LENGUAJE DE CONSULTA ESTRUCTURADO El lenguaje de consulta estructurado (SQL) es otra manera popular
de implementar consultas. Utiliza una serie de palabras y comandos para seleccionar las filas y columnas que
deben aparecer en la tabla resultante. La figura 14.23 contiene código de SQL. La palabra clave SELECT
DISTINCTROW determina las filas que se van a seleccionar. La palabra clave WHERE especifica la condición
que debe usar el NOMBRE CLIENTE para seleccionar los datos introducidos en el parámetro LIKE.
FIGURA 14.21
Consulta mediante ejemplos en
Microsoft Access.
FIGURA 14.22
Una consulta mediante ejemplo
para ESTADO CLIENTE
(CUSTOMER STATUS) produce
estos resultados.www.xlibros.com

474 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
SELECT DISTINCTROW
Cliente.[Numero cliente],
Cliente.[Nombre cliente],
Cliente.Ciudad,
Cliente.Telefono
FROM Cliente
WHERE (((Cliente.[Nombre cliente])
Like ([Escriba un Nombre de cliente parcial] & "*")));
FIGURA 14.23
Lenguaje de consulta estructurado
(SQL) para la consulta del
parámetro NOMBRE CLIENTE.
RESUMEN
PALABRAS CLAVE Y FRASES
ajuste
aplicación web híbrida (mashup)
asistente
barra de navegación
consideraciones cognoscitivas de HCI
consideraciones físicas de la HCI
consideraciones psicológicas de la HCI
consulta
consulta mediante ejemplo
cuadro de diálogo
desempeño
discapacidades y diseño
interfaces de llenado de formularios (formularios de entrada/
salida)
interfaz de lenguaje de comandos
interfaz de lenguaje natural
interfaz de llenado de formulario basado en Web
interfaz de preguntas y respuestas
interfaz de programación de aplicaciones (API)
interfaz gráfica de usuario (GUI)
lenguaje de consulta estructurado (SQL)
mapa del sitio
menú
menú con rollover
menú desplegable
menús anidados
modelo de aceptación de la tecnología (TAM)
navegación de un solo clic
navegación intuitiva
operadores booleanos
pantalla sensible al tacto
pantalla táctil
pegajosidad
plantilla
plumilla
reconocimiento y síntesis de voz
retroalimentación
retroalimentación para los usuarios
sistema continuo de voz
tarea
capacidad de usabilidad
Examinamos la interacción humano-computadora (HCI), una
variedad de interfaces, el diseño de la interfaz de usuario, el diseño
de la retroalimentación del usuario y el diseño de la retroalimen-
tación y navegación de sitios Web de comercio electrónico. Nos
enfocamos en comprender la HCI para asegurar la funcionalidad
y usabilidad de los sistemas computacionales que diseñamos.
Cuando los analistas crean un ajuste apropiado entre los elemen-
tos de la HCI del humano, la computadora y la tarea, se produce
una mejora en el rendimiento y un bienestar psicológico y físico
del individuo en general.
Los diseños se enfocan en desarrollar un ajuste apropiado.
Los analistas pueden usar el TAM (Modelo de aceptación de la
tecnología) para organizar su modo de pensar acerca de si los
usuarios aceptarán la tecnología y la utilizarán en un momento
dado, mediante un análisis de la utilidad y facilidad de uso per-
cibidas desde la perspectiva del usuario.
La usabilidad identifica lo que funciona y no funciona para los
usuarios. Las consideraciones físicas del diseño de la HCI incluyen
visión, oído y tacto. Hay que tener en cuenta las discapacidades y
limitaciones físicas durante el diseño de tareas e interfaces. Hay
gran variedad de interfaces de usuario y dispositivos de salida.
Algunas interfaces se adaptan muy bien a los usuarios inexpertos,
mientras que otras se adaptan mejor a los usuarios experimentados.
Combine interfaces como menús desplegables e interfaces gráficas
para aumentar la efectividad. La Web ha impuesto nuevos retos
para los diseñadores, ya que no conocen al usuario.
La necesidad que tienen los usuarios de retroalimentación
del sistema es también una consideración importante. La retroa-
limentación es casi siempre visual, siendo el texto, los gráficos
y los iconos los tipos más comunes de retroalimentación visual.
La retroalimentación de audio también puede ser efectiva.
Para mejorar la funcionalidad de los sitios Web hay que
obtener retroalimentación del cliente por medio de botones de
retroalimentación automática por correo electrónico o mediante
la inclusión de formularios en blanco en el sitio Web. Cuatro
estrategias importantes de diseño de navegación mejoran la pe-
gajosidad de los sitios Web de comercio electrónico: 1) menús
con rollover, 2) visualizaciones jerárquicas de vínculos en la
pantalla de entrada; 3) mapas del sitio y 4) barras de navegación
que ofrecen la navegación con un solo clic.
Las consultas están diseñadas para permitir a los usuarios
extraer datos significativos de la base de datos. Hay seis tipos
básicos de consultas que se pueden combinar mediante el uso de
lógica booleana para formar consultas más complejas. La con-
sulta mediante ejemplo y el SQL son dos formas comunes de
consultar sistemas de bases de datos.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 475
E X P E R I E N C I A D E H Y P E R C A S E ® 1 4
“ No tengo problema en usar un ratón o cualquier otro roedor
que se me atraviese. Pero en realidad, lo que Snowden necesita es
lo que trato de hacer. Sin embargo, todo es distinto. He visto perso-
nas aquí que han hecho de todo por evitar usar una computadora;
otras preferirían no hablar con un humano. De hecho, estarían tan
felices como un cachorro masticando un zapato si pudieran usar el
lenguaje de comandos para interactuar. La mayoría de los compa-
ñeros que tenemos aquí están abiertos a nuevas cosas. De lo contra-
rio no estarían en MRE. Nos enorgullecemos de nuestra creatividad.
Lo anoté para una reunión con personal del grupo de capacitación,
incluyendo a Tom Ketchem, Melissa Smith y Kathy Blandford.
Incluí a Ashley Heatherford, quien es nuestra consultora experta en
usabilidad. Melanie Corazón podría estar también en la junta, ya
que quiere ver si lo que usted está haciendo se puede aplicar a los
sistemas de comercio electrónico. Tal vez Snowden asista también,
si tiene tiempo. Todos tienen mucha curiosidad de ver el tipo de
interfaz que usted va a sugerirles para el nuevo proyecto del sistema
de informes”.
Preguntas de HYPERCASE
1. Escriba una breve propuesta en la que describa el tipo de
interfaz de usuario que sería apropiada para los usuarios del
sistema de informes de proyectos que están en el grupo de
capacitación. Incluya las razones de su decisión.
2. Diseñe una interfaz de usuario mediante el uso de una
herramienta CASE como Visible Analyst, un paquete de
software tal como Microsoft Access o formularios de diseño
en papel para el grupo de capacitación. ¿Cuáles son las
características clave que tienen como fin satisfacer las
necesidades de las personas del grupo de capacitación?
3. Escriba una breve propuesta en la que describa el tipo de
interfaz de usuario que sería apropiada para los usuarios
de los sistemas de comercio electrónico B2B que Melanie
Corazón describió en su entrevista. Incluya las razones de su
decisión.
4. Diseñe una interfaz de usuario mediante una herramienta
CASE como Visible Analyst, un paquete de software como
Microsoft Access o formularios de diseño en papel para los
usuarios de los sistemas de comercio electrónico B2B que
describió Melanie Corazón. ¿Cuáles son las características
clave que lidian con las necesidades de las personas que
utilizan sistemas de comercio electrónico B2B en la Web?
5. Haga una lista con viñetas de las cuestiones de usabilidad
que podría Ashley tener con las interfaces que diseñó.
FIGURA 14.HC1
En HyperCase podrá ver cómo los usuarios procesan información para poder crear una
interfaz de usuario más efectiva.www.xlibros.com

476 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
PREGUNTAS DE REPASO
1. Defina HCI.
2. Explique cómo el ajuste entre los elementos de HCI del humano, la computadora y las tareas a
desempeñar conducen a un buen desempeño y bienestar.
3. ¿Cuáles son los componentes del término desempeño en el contexto de la HCI?
4. ¿Qué significa la palabra bienestar cuando se utiliza en una metodología de la HCI?
5. ¿Cuáles son las dos variables del Modelo de aceptación de la tecnología (TAM)?
6. Haga una lista de cinco de las once heurísticas de usabilidad para juzgar la usabilidad de los sistemas
computacionales y los sitios Web de comercio electrónico proporcionados por Nielsen y otros.
7. Describa algunas de las formas en que una tabla dinámica permite a un usuario ordenar datos.
8. Mencione tres consideraciones físicas de las que el diseño de HCI se ocupa.
9. Mencione tres formas en que los analistas pueden mejorar el diseño de tareas o de interfaces para
ayudar, en forma respectiva, a una persona con discapacidad visual, auditiva o móvil.
10. ¿Cuáles son los cinco objetivos para diseñar interfaces de usuario?
11. Defina las interfaces de lenguaje natural. ¿Cuál es su mayor desventaja?
12. Explique lo que significa interfaces de pregunta y respuesta. ¿A qué tipo de usuarios están mejor
acostumbrados?
13. Describa cómo utilizan los usuarios los menús en pantalla.
14. ¿Qué es un menú anidado? ¿Cuáles son sus ventajas?
15. Defina los formularios de entrada/salida en pantalla. ¿Cuál es su principal ventaja?
16. ¿Cuáles son las ventajas de los formularios de llenado basados en Web?
17. ¿Cuáles son las desventajas de las interfaces de formularios de llenado basados en Web?
18. Explique lo que son las interfaces de lenguaje de comandos. ¿A qué tipo de usuarios se adaptan mejor?
19. Defina las interfaces gráficas de usuario. ¿Cuál es la dificultad clave que presentan para los
programadores?
20. ¿Para qué tipo de usuario es una GUI especialmente efectiva?
21. ¿Cuáles son los tres lineamientos para diseñar un buen diálogo en pantalla?
22. ¿Cuáles son las funciones de los iconos, gráficos y color para proporcionar retroalimentación?
23. Mencione ocho formas para lograr el objetivo de la acción mínima del operador al diseñar una
interfaz de usuario.
24. Mencione cinco estándares que puedan ayudar a evaluar interfaces de usuario.
25. ¿Cuáles son las siete situaciones que requieren retroalimentación para los usuarios?
26. ¿Cuál es una manera aceptable de decir al usuario que se aceptó la entrada?
27. Cuando se informa a un usuario que su entrada no está en el formato correcto, ¿qué retroalimentación
adicional hay que proporcionar al mismo tiempo?
28. Mencione tres formas de notificar a un usuario Web que la entrada no está en el formato correcto.
29. ¿Por qué es inaceptable notificar al usuario que la entrada no es correcta sólo mediante el uso de
sonidos o zumbidos audibles?
30. Cuando no se completa una solicitud, ¿qué retroalimentación hay que proveer al usuario?
31. Describa dos tipos de diseños de sitios Web para obtener retroalimentación de los clientes.
32. Mencione cuatro formas prácticas en las que un analista puede mejorar la facilidad de navegación del
usuario y la pegajosidad de un sitio Web de comercio electrónico.
33. ¿Qué son vínculos de hipertexto? ¿Dónde se deben usar?
34. Describa qué es una aplicación web híbrida (mashup).
35. Haga una lista con notación abreviada de los seis tipos de consultas básicas.
PROBLEMAS
1. Manu Narayan es dueño de varios hoteles de primera clase en todo el mundo, incluyendo
propiedades en Manhattan, Mumbai e incluso algunos en los suburbios. Él desea asegurarse de que la
interfaz humano-computadora sea apropiada para cada cultura, pero también desea poder compartir
el software entre todos los departamentos de reservaciones de sus hoteles. Diseñe una interfaz de
menús anidados para un sistema de reservaciones de llegadas y partidas del hotel que se pueda usar a
nivel internacional. Utilice números para seleccionar cada elemento del menú. Muestre cómo luciría
cada menú en una pantalla de computadora.
2. Stefan Lano necesita pantallas para mostrar el inventario de instrumentos musicales en su cadena de
tiendas de música, que da servicio a músicos que tocan en orquestas sinfónicas de clase mundial en
Basel, Suiza; Buenos Aires, Argentina; Filadelfia y Nueva York, E.U. Diseñe una interfaz de llenado
de formularios para el control de inventario de los instrumentos musicales en las cuatro tiendas que
se pueda usar en una pantalla de PC. Suponga que el español será el lenguaje de interfaz.
3. Diseñe una interfaz de llenado de formularios basados en Web para realizar la misma tarea que en el
problema 2.
a. ¿Qué dificultades encontró? Descríbalas en un párrafo.
b. De los dos diseños que hizo, ¿cuál podría decir que se adapta mejor a la tarea del Sr. Lano? ¿Por
qué? Mencione tres razones de su elección. ¿Cómo evaluaría su usabilidad?
4. Una agencia de viajes ubicada en el Reino Unido, Euan Morton, LLC, desea que el equipo de
sistemas que usted dirige diseñe una interfaz de lenguaje de comandos que pueda usar para reservarwww.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 477
asientos para las aerolíneas con las que su empresa tiene sólidos lazos comerciales, como British Air, RyanAir y Virgin
Atlantic.
a. Muestre cuál sería la apariencia de la interfaz en una pantalla estándar.
b. Haga una lista de los comandos necesarios para reservar un asiento de la aerolínea y anote lo que significa cada
comando.
5. Una ejecutiva de Ti de nombre Felicia Finley que proviene de Jersey IT Innovators, Inc., le ha pedido que diseñe una
interfaz gráfica de usuario para un escritorio ejecutivo que le pueda ayudar en su trabajo. Use iconos para los archiveros,
un bote de basura, un teléfono, etcétera. Muestre cuál sería su apariencia en la pantalla de computadora.
6. Nick, famoso chef y propietario de un restaurante de Williamsburg, Nueva York, desea poder recibir una
retroalimentación clara en los sistemas que se utilizan para administrar sus diversos restaurantes de “atracción turística”.
Diseñe una pantalla que provea una retroalimentación apropiada para un usuario cuyo comando no se pueda ejecutar.
7. Diseñe una pantalla para un paquete de software de nómina que muestre información para indicar a Nick, del problema 6,
cómo puede obtener una retroalimentación más detallada.
8. Diseñe una pantalla basada en Web que muestre una manera aceptable de decir a Nick que se aceptó la entrada de su sistema.
9. Diseñe un formulario de retroalimentación para los clientes del restaurante de Nick mediante el uso de un sitio Web de
comercio electrónico.
10. Escriba seis consultas para el archivo en el problema 1 del capítulo 13.
11. Escriba seis consultas para la relación en 3NF en el problema 5 del capítulo 13.
12. Diseñe una búsqueda que encuentre los potenciales competidores de una empresa como World’s Trend en la Web.
Suponga que usted es el cliente.
13. Busque los potenciales competidores de World’s Trend en la Web (no encontrará a la empresa World’s Trend en la Web,
ya que es una compañía ficticia). Haga una lista de los que encuentre.
PROYECTOS EN GRUPO
1. Con los miembros de su grupo, cree un menú desplegable para una agencia de empleos que relacione los potenciales
candidatos con las vacantes disponibles. Incluya una lista de teclas para seleccionar directamente las opciones del menú;
utilice el formato Alt-X. El menú tiene las siguientes opciones:
2. Describa en un párrafo los problemas que su grupo enfrentó al crear este menú.
3. La característica de arrastrar y soltar se utiliza en las GUI y permite al usuario mover enunciados en un programa de
procesamiento de palabras. Como grupo, sugiera cómo se podría utilizar la técnica de arrastrar y soltar a su máximo
potencial en las siguientes aplicaciones:
a. Software de administración de proyectos (capítulo 3).
b. Programa de bases de datos relacionales (capítulo 13).
c. Diseñador de pantallas o formularios (capítulo 12).
d. Programa de hoja de cálculo.
e. Herramienta CASE para dibujar diagramas de flujo de datos (capítulo 7).
f. Programa de fax (capítulo 11).
g. Calendario de asistente personal digital (PDA) (capítulo 3).
h. Ilustración en un paquete de dibujo.
i. Herramienta CASE para desarrollar diccionarios de datos (capítulo 8).
j. Programa para dibujar árboles de decisión (capítulo 9).
k. Sitio Web para recolectar opiniones del consumidor sobre nuevos productos (capítulo 11).
l. Organizar marcadores para sitios Web.
Para cada solución que diseñe su grupo, dibuje la pantalla y muestre el movimiento mediante el uso de una flecha.
4. Pida a los miembros de su grupo que soliciten una búsqueda con base en sus actividades de entretenimiento. Si hay
cuatro personas en su grupo, habrá que realizar cuatro búsquedas únicas. Ahora vaya y realice todas las búsquedas.
Compare sus resultados. ¿Tiene la persona involucrada con la actividad una ventaja sobre las personas que saben menos
sobre ella? Explique.
5. Analice los siguientes sitios Web de aplicaciones web híbridas y describa cómo es que cada uno de ellos agrega un valor
al proveer un servicio.
a. Aboutairportparking.com, www.aboutairportparking.com
b. Baebo, http://baebo.francisshanahan.com
c. Global Incident Map, www.globalincidentmap.com/home.php
Agregar empleado Eliminar empleado
Modificar empleado Relacionar empleado con vacante
Eliminar empleado Imprimir informe de vacantes disponibles
Consulta de empleados Imprimir informe de coincidencias exitosas
Consulta de empleos Agregar vacante
Consulta de patrones Modificar vacante
Agregar patrón Eliminar vacante
Modificar patrónwww.xlibros.com

478 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
d. Hawkee Technology Social Network, www.hawkee.com
e. Homethinking, www.homethinking.com
f. Sitios de compras en mpire, www.mpire.com/buyer/search.page
g. Streeteasy, www.streeteasy.com
6. Los siguientes dos aplicaciones web híbridas tienen fines de propaganda política; sugiera otras tres
que traten de modificar algo atrayendo al público.
Cuidado de la salud que funciona, www.healthcarethatworks.org/maps/nyc
Y también pruebe en NYTurf,
7. Pruebe estas aplicaciones web híbridas sólo por diversión.
a. La geografía de Seinfeld, www.stolasgeospatial.com/senfield.html
b. HBO: Los Sopranos www.hbo.com/sopranos/map
c. PlotShot, www.plotshot.com
d. Flickr Sudoku, http://flickrsudoku.com
e. Liveplasma, www.liveplasma.com
BIBLIOGRAFÍA SELECCIONADA
Adam, A. y D. Kreps. “Web Accessibility: A Digital Divide for Disabled People?” En Societal and Organi-
zational Implications for Information Systems, IFIP Federación Internacional para el Procesamiento de
la Información, Vol. 208. Editado por E. Trauth, D. Howcraft, T. Butler, B. Fitzgerald y J. DeGross, pp.
217-228. Boston: Springer, 2006.
Barki, H. y J. Hartwick. “Measuring User Participation, User Involvement, and User Attitude”. MIS Quar-
terly, Vol. 18, Núm. 1, 1994, pp. 59-82.
Berstel, J., S. C. Reghizzi, G. Roussel y P. San Pietro. “A Scalable Formal Method for Design and Automa-
tic Checking of User Interfaces”. ACM Transactions on Software Engineering and Methodology, Vol.
14, Núm. 2, abril de 2005, pp. 124-167.
Carey, J., D. Galletta, J. Kim, D. Te’eni, B. Wildemuth y P. Zhang. “The Role of Human-Computer Interac-
tion in Management Information Systems Curricula: A Call to Action”. Communications of the Asso-
ciation for Information Systems, Vol. 13, 2004, pp. 357-379.
Davis, F. “Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology”.
MIS Quarterly, Vol. 13, Núm. 3, 1989, pp. 319-340.
Davis, G. B. y M. H. Olson. Management Information Systems: Conceptual Foundations, Structure, and
Development. Nueva York: McGraw-Hill, 1985.
Galleta, D. y P. Zhang (Eds.). Human-Computer Interaction and Management Information Systems: Appli-
cations. Armonk, NY: M. E. Sharpe, 2006.
Greene, K. “A Better, Cheaper Multitouch Interface”. Technology Review, marzo 2009, www.technologyre-
view.com/computing/22358/?a=f. Último acceso el 19 de abril de 2009.
Hornbaek, K. y E. Frokjaer. “Comparing Usability Problems and Redesign Proposals as Input to Practical
Systems Development”. CHI 2005, abril 2-7, 2005, pp. 391-400.
Mantei, M. M. y T. J. Teorey. “Incorporating Behavioral Techniques in the System Development Lifecycle”.
MIS Quarterly, Vol. 13, Núm. 3, septiembre 1989, pp. 257-267.
Nielsen, J. y R. L. Mack. Usability Inspection Methods. Nueva York: John Wiley, 1994.
Nielsen, J., R. Molich, C. Snyder y S. Farrell. E-Commerce User Experience. Fremont, CA: Norman Nielsen
Group, 2001.
Rubin, J. Handbook of Usability Testing. Nueva York: John Wiley, 1994.
Schneiderman, B. y C. Plaisant. Designing the User Interface: Strategies for Effective Human-Computer
Interaction. Nueva York: Addison-Wesley, 2005.
Te’eni, D. J. Carey y P. Zhang. Human Computer Interaction: Developing Effective Organizational Systems.
Nueva York: John Wiley, 2007.
Departamento de salud y servicios humanos de los EE.UU. “Guía de usabilidad” (para desarrollar sitios
Web). Disponible en www.usability.gov. Último acceso el 19 de abril de 2009.
Comisión para la Igualdad de Oportunidades en el Empleo de los EE.UU., sitio Web que lista las obligacio-
nes del patrón bajo la Ley de estadounidenses con discapacidades. Disponible en www.eeoc.gov/types/
ada.html. Último acceso el 19 de abril de 2009.
UsabilityNet. “Overview of the User Centered Design Process”. Disponible en: www.usabilitynet.org/
management/b_overview.htm. Último acceso el 19 de abril de 2009.
Venkatesh, V., M. G. Morris, G. B. Davis y F. D. Davis. “User Acceptance of Information Technology:
Toward a Unified View”. MIS Quarterly, Vol. 27, Núm. 3, 2003, pp. 425-478.
Zhang, P., J. Carey, D. Te’eni y M. Tremaine. “Integrating Human-Computer Interaction Development into
the System Development Life Cycle: A Methodology”. Communications of the Association for Infor-
mation Systems, Vol. 15, 2005, pp. 512-543.
Zhang, P. y D. Galleta (Eds.). Human Computer Interaction and Management Information Systems: Foun-
dations. Armonk, NY: M.E. Sharpe, 2006.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 479
E P I S O D I O 1 4
Caso de la CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Depende de los usuarios
“Tomemos nuestros prototipos junto con algunas de las nuevas pantallas, informes y formularios para crear la interfaz de usua-
rio final”, dice Anna a Chip.
“Todo es cuestión de tiempo, ¿no es así?”, responde Chip. Estaba demasiado consciente de la importancia de diseñar una
buena interfaz. “Me gustaría tener en cuenta todos los factores de la interfaz humano-computadora. Creo que cuando termine-
mos, deberíamos hacer que los usuarios completen una encuesta de usabilidad”.
“¡De acuerdo!”, exclama Anna. “Vamos a delinear y definir nuestros lineamientos”.
Después de hablar establecen los siguientes lineamientos para los diálogos de las pantallas:
1. Las pantallas bien diseñadas deben:
Comunicar las acciones e intenciones con claridad a los usuarios.
Mostrar las opciones disponibles para los operadores, ya sea mediante el uso de texto o iconos. Algunos ejemplos son:
HAGA LAS CORRECCIONES U OPRIMA ESC PARA CANCELAR
INTRODUZCA EL NÚMERO DE INVENTARIO DE HARDWARE
OPRIMA LA TECLA INTRO
OPRIMA INTRO PARA CONFIRMAR ELIMINACIÓN, ESC PARA CANCELAR
Botones que digan Aceptar o Cancelar
Estandarizar el uso de las abreviaturas.
Evitar el uso de códigos, substituir el significado de los códigos.
Proveer pantallas de ayuda para las porciones complicadas del diálogo.
Proveer ayuda en cuadros de información sobre las herramientas para los iconos de las barras de herramientas.
2. Hay que proveer retroalimentación a los usuarios. Se incluye lo siguiente:
Títulos para mostrar la página actual.
Mensajes de acciones completadas con éxito, como:
SE AGREGÓ EL REGISTRO
SE MODIFICÓ EL REGISTRO
Mensajes de error. Algunos ejemplos son:
FECHA INVÁLIDA
DEBE INCLUIR UN NÚMERO
EL SOFTWARE NO ESTÁ EN EL ARCHIVO
Un cuadro de diálogo de datos inválidos, con un botón Aceptar en una pantalla de interfaz gráfica de usuario.
Procesar mensajes de retraso similares a:
POR FAVOR ESPERE, SE ESTÁ GENERANDO EL INFORME
Un reloj de arena que gire boca abajo en una interfaz gráfica de usuario.
3. Debe haber consistencia en el diseño, incluyendo:
La ubicación de la ayuda breve en el área de la línea de estado. Las páginas Web deben incluir instrucciones y una
opción de ayuda que se indique con claridad.
Fecha y hora en las áreas de encabezado.
Salida consistente de todas las pantallas; por ejemplo, a través del uso de la misma acción o botón de retroceso en las
páginas Web.
Uso estándar de iconos o botones, para mostrar una página anterior o siguiente en una pantalla de varias páginas.
Método consistente para cancelar una operación; por ejemplo, mediante el uso de la tecla Esc. Uso estandarizado de
color y pantalla de alta intensidad; por ejemplo, que aparezcan todos los mensajes en rojo.
Uso estandarizado de iconos e imágenes en las páginas Web y pantallas.
Menús desplegables estandarizados para las páginas Web y en otras pantallas.
4. Hay que requerir las acciones mínimas del operador para poder usar el sistema. Algunos ejemplos son:
Al modificar o eliminar registros, sólo hay que especificar la clave del registro. El sistema obtiene el registro y muestra
la información pertinente.
Cuando se requieren nombres como entradas de clave, sólo hay que introducir las primeras letras del nombre. El
programa usa la coincidencia parcial o Ajax para las páginas Web, de manera que se encuentren todos los nombres
clave de los registros que coincidan y se presenten para que el operador los seleccione.
Todas las entradas numéricas pueden omitir los ceros a la izquierda y las comas.
A medida que se completa cada campo de datos, el cursor debe avanzar al siguiente campo de entrada. El usuario debe
poder avanzar con el tabulador en los campos, en la secuencia correcta.www.xlibros.com

480 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
Después de completar cada opción, hay que volver a mostrar la misma pantalla, con las áreas de entrada en blanco, hasta
que se haga clic en el icono Salir.
Al salir de una opción hay que mostrar el menú anterior.
Hay que utilizar listas desplegables siempre que sea posible en las pantallas Web y de GUI.
Hay que usar casillas de verificación y botones de opción para realizar selecciones siempre que sea posible.
Los botones predeterminados deben estar delineados de tal forma que el usuario pueda oprimir Intro para seleccionarlos.
5. Hay que validar los datos que entran al sistema. Los lineamientos son:
Los campos específicos se deben verificar de acuerdo a los criterios de edición.
A medida que se detecten errores, los operadores deben recibir la oportunidad de aceptar o realizar correcciones a los
datos introducidos.
Cuando no se detecten errores en una transacción, hay que presentar la entrada al operador para una confirmación visual.
El operador debe tener la oportunidad de aceptarla o de hacer las correcciones en los datos introducidos.
Al examinar las diversas pantallas e informes (aproximadamente 30 en Access, así como muchas páginas Web), Chip y
Anna deciden dividir el menú en varias funciones. “¿Cómo dividimos estas diversas funciones en un conjunto de menús?”,
preguntó Chip.
“¿Por qué no usamos un diagrama de descomposición para organizar las funciones en una jerarquía?”, respondió Anna.
Chip y Anna empiezan a trabajar en el diagrama. Las interacciones del menú se representarán en una estructura jerárquica, en
donde las opciones se mostrarán en rectángulos y el menú en general se representará mediante el rectángulo en la parte superior.
Cada menú secundario aparecerá debajo del menú principal, con los programas de pantalla en el nivel más bajo. El menú
principal tendrá seis opciones principales, como se muestra en la figura E14.1: 1) Actualizar software (Update Software),
2) Actualizar hardware (Update Hardware), 3) Consultar (Inquiry), 4) Modificar códigos (Modify Codes), 5) Capaci-
tación (Training) y 6) Informe (Report). Cada una de estas opciones se subdivide en menús más pequeños o en funciones
individuales. El Menú Consulta se subdivide en dos menús más pequeños, Opciones de software (Software Options) y
Opciones de hardware (Hardware Options), así como una opción para ejecutar la Consulta para el experto de software
(Software Expert Inquiry).
Menú principal
del sistema
de cómputo
Menú Consultar
Menú
Modificar
códigos
Menú
Capacitación Menú Informe
Menú
Actualizar
hardware
Menú
Actualizar
software
Opciones
de software
Consulta
para el experto
de software
Opciones
de hardware
Consulta de
detalles
de hardware
Consulta de
características
de hardware
FIGURA E14.1
Jerarquía de pantallas para el
sistema de cómputo.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 481
Los rectángulos en el diagrama de descomposición funcional se implementan mediante una serie de listas de menús des-
plegables, las cuales se muestran en la figura E14.2. Cabe mencionar que el menú Consulta tiene funciones que corresponden
a los rectángulos en la figura anterior. Se incluye una fila de botones para las funciones comunes debajo de los menús. Las
funciones de menú se incluyen como un conjunto de botones en el área principal de la pantalla; se puede hacer clic en estos
botones para ejecutar los programas correspondientes. Se decidió que los programas Agregar computadora (Add Computer),
Agregar paquete de software (Add Software Package) y Modificar computadora (Change Computer) se ejecutarían di-
rectamente desde el menú principal. Al hacer clic en los otros botones aparecen los cuadros de diálogo de selección, con opcio-
nes para seleccionar programas.
“También vamos a incluir menús desplegables para las páginas”, comenta Anna. “Éstos utilizan un índice z para colocarlos
enfrente de la página Web. Se despliegan cuando el usuario coloca el ratón encima de ellos y desaparecen cuando quita el ratón
de ellos.
“Algunas veces eso puede ser molesto”, recalca Chip. “La página Web destella constantemente los menús cuando se mueve
el ratón sobre la página”.
“Podemos agregar un retraso para que el despliegue ocurra cuando el ratón esté encima durante más de un breve segundo”,
dice Anna en tono pensativo.
“Estos menús deben ser consistentes para el conjunto de páginas y formularios Web”, reflexiona Chip. “Podemos usar el
mismo código y estilos en varias páginas Web”.
Después de cierta deliberación cuidadosa, el diseño de los menús Web está completo. La figura E14.3 muestra el menú
final.
FIGURA E14.2
Menú principal para el sistema
de la computadora.
FIGURA E14.3
Un menú Web de la CPU que
muestra las opciones desplegables
que aparecen frente a la página
Web principal.www.xlibros.com

482 PARTE IV • LOS FUNDAMENTOS DEL DISEÑO
“He aquí lo que pienso que deberían ser los lineamientos para los programas de actualización”, dice Anna a Chip. “El
enfoque clave está en la precisión, con una capacidad detallada de edición para cada campo de datos. Agregar programas (Add
programs) mostrará una página de entrada y permitirá crear registros de hardware o software. Después de completar todas las
entradas, el usuario debería verificar los datos dos veces y después hacer clic en el botón Agregar registro de software (Add
Software Record). Cualquier dato que ya se encuentre en el sistema deberá implementarse mediante el uso de listas desplega-
bles. También hay botones para deshacer cambios, mover información a otros registros, imprimir un registro, guardar los cam-
bios y salir de la página. Se puede agregar un registro sólo si no existe de antemano la clave primaria para ese registro”.
“Las pantallas de eliminación deben tener una entrada simple de clave primaria, como DESCRIPCION CURSO (COURSE
DESCRIPTION) en la pantalla ELIMINAR CURSO SOFTWARE (DELETE SOFTWARE COURSE)”, continúa Anna. “La
pantalla ELIMINAR CURSO SOFTWARE usa un botón Buscar (Find) (los binoculares) para ayudar a localizar el registro
deseado. Se lee el registro correspondiente y se muestra la información en pantalla. Los usuarios hacen clic en el botón Eliminar
(Delete) y se les pide que confirmen la eliminación. Si el usuario hace clic en la tecla Esc o en Cancelar (Cancel), se cancela la
acción de eliminar. ¿Qué te parece todo esto?”, pregunta a Chip.
“Hasta ahora todo bien”, le contesta. “¿Algo sobre pantallas en las que se puedan modificar datos?”.
“Sí. Se introduce una clave primaria para el registro y se lee el registro que coincida. Aparece la información del registro
y el operador puede sobrescribir los datos con sus modificaciones. Hay que validar todas las modificaciones con capacidad de
edición completa. Cuando todos los campos que se modificaron sean válidos, el usuario debe hacer clic en un botón para guar-
darlos. ¿Está lo bastante claro para el usuario?”, pregunta Anna.
“Creo que está muy bien”, responde Chip. “Pienso que hemos tenido un buen inicio con el diseño de nuestras interfaces
de usuario”.
EJERCICIOS
E-1. Use Microsoft Access para ver las opciones del menú para el sistema computacional.
E-2. Examine la CONSULTA HARDWARE (HARDWARE INQUIRY). Explique el tipo de consulta utilizando la notación
de valor, entidad y atributo (V, E, A).
E-3. Explique en un párrafo por qué una pantalla para introducir datos debe hacer énfasis en la precisión, mientras que una
pantalla de consulta hace énfasis en la rapidez con que se pueden mostrar los datos.
E-4. Modifique e imprima el diagrama de jerarquías que representa al menú Actualizar Hardware (Update Hardware). El
nombre del archivo en Microsoft Visio es Update Hardware. Agregue rectángulos para representar las siguientes opciones
del menú:
MODIFICAR COMPUTADORA (CHANGE COMPUTER)
ELIMINAR REGISTRO COMPUTADORA (DELETE COMPUTER RECORD)
ACTUALIZAR COMPUTADORA INSTALADA (UPDATE INSTALLED COMPUTER)
E-5. Use el diagrama Estructura del programa (Program Structure) de Microsoft Visio o el diagrama Descomposición fun-
cional (Functional Decomposition) en Visible Analyst para dibujar un diagrama de jerarquías que represente las opcio-
nes que se encuentran en el menú Actualizar Software (Update Software). Empiece con el rectángulo superior que
representa al menú Actualizar Software.
AGREGAR PAQUETE SOFTWARE (ADD SOFTWARE PACKAGE)
MODIFICAR REGISTRO SOFTWARE (CHANGE SOFTWARE RECORD)
ELIMINAR REGISTRO SOFTWARE (DELETE SOFTWARE RECORD)
ACTUALIZAR PAQUETE SOFTWARE (UPGRADE SOFTWARE PACKAGE)
E-6. Chip y Anna descubren que el menú que han diseñado es para los usuarios involucrados en la instalación y mantenimiento
de hardware y software de computadora. Este menú no sería adecuado para los miembros del personal y del cuerpo do-
cente en general, ya que no tienen la habilidad de actualizar los registros. Diseñe un menú, ya sea en papel o mediante el
uso de software con el que esté familiarizado, para proveer al usuario general la habilidad de realizar consultas y ver
informes.
E-7. Describa en un párrafo por qué los usuarios tendrían que cambiar a otra página (oprimiendo el botón Siguiente registro
[Next Record]) para mostrar el registro correcto para la consulta UBICACION SOFTWARE (SOFTWARE LOCA-
TION).
E-8. Diseñe la pantalla de consulta DETALLES SOFTWARE (SOFTWARE DETAILS). El campo de entrada es NUMERO
INVENTARIO SOFTWARE (SOFTWARE INVENTORY NUMBER) y deberá aparecer toda la información de soft-
ware, con la excepción de EXPERTO (EXPERT) y MAQUINAS INSTALADAS EN (MACHINES INSTALLED ON).
Consulte la entrada en el repositorio del flujo de datos DETALLES DE SOFTWARE de Visible Analyst o la página Web
del repositorio.www.xlibros.com

CAPÍTULO 14 • INTERACCIÓN HUMANO-COMPUTADORA 483
E-9. Para programar los horarios de los salones de clase que utilizarán los estudiantes, Cher Ware necesita conocer todos los
paquetes de software disponibles en una sala específica. Lo que ella desea es introducir la UBICACION CAMPUS
(CAMPUS UBICATION) y la SALA (ROOM) en una pantalla de consulta. Los campos serían TITULO (TITLE), VER-
SION, LICENCIA SITIO (SITE LICENSE) y NUMERO DE COPIAS (NUMBER OF COPIES).
Diseñe la consulta SOFTWARE POR SALA (SOFTWARE BY ROOM), que se describe como flujo de datos en la
página Web del repositorio o en el repositorio de Visible Analyst.
E-10. De vez en cuando, Hy Perteks recibe una solicitud de ayuda relacionada con cierto paquete de software específico. Los
miembros del personal y los estudiantes necesitan realizar opciones avanzadas o transferir datos entre distintos paquetes
y tienen dificultades para hacerlo. A Hy le gustaría introducir el TITULO (TITLE) y NUMERO VERSION (VERSION
NUMBER) del software. La pantalla resultante debería mostrar el NOMBRE EXPERTO SOFTWARE (SOFTWARE
EXPERT NAME) junto con la UBICACION CAMPUS (CAMPUS LOCATION) y el NUMERO SALA (ROOM NUM-
BER). Diseñe la pantalla para la consulta LOCALIZAR EXPERTO SOFTWARE (LOCATE SOFTWARE EXPERT).
Describa la lógica y los archivos necesarios para producir la consulta. Use la notación de valor, entidad y atributo (V, E, A)
para esta consulta. Los detalles de la consulta se incluyen en la entrada en el repositorio para el flujo de datos EXPERTO
SOFTWARE (SOFTWARE EXPERT) de Visible Analyst o la página Web del repositorio.
E-11. Hy recibe varias solicitudes de clases de capacitación. A él le gustaría planear la capacitación y colocar las clases próxi-
mas a impartir en intranet, para que el cuerpo docente tenga una cantidad adecuada de tiempo anticipado para programar
una clase. Diseñe la consulta CLASES CAPACITACION SOFTWARE (SOFTWARE TRAINING CLASSES). Encon-
trará los detalles en la página Web del repositorio o en la entrada en el repositorio de flujo de datos de Visible Analyst
llamada CLASES CAPACITACION SOFTWARE (SOFTWARE TRAINING CLASSES).
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.www.xlibros.com

www.xlibros.com

485
C A P Í T U L O 1 5
Diseño de procedimientos
precisos de entrada de datos
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Comprender los usos de la codificación efectiva para apoyar a los usuarios en la
realización de sus tareas.
2. Diseñar metodologías efectivas y eficientes de captura de datos para las personas y los
sistemas.
3. Reconocer cómo asegurar la calidad de los datos por medio de la validación.
4. Articular las ventajas de la precisión de la entrada de los usuarios en los sitios Web de
comercio electrónico.
Es de suma importancia asegurar que los usuarios puedan introducir datos en
el sistema con precisión. A estas alturas es claro que la calidad de la entrada de
datos determina la calidad de la salida de información. El analista de sistemas
puede apoyar la entrada de datos con precisión por medio de la obtención de
cuatro objetivos generales: 1) crear una codificación significativa para los datos,
2) diseñar metodologías eficientes de captura de datos, 3) asegurar una captura
de datos completa y efectiva, y 4) asegurar la calidad de los datos por medio de la validación.
La calidad de los datos es una medida de la consistencia y precisión de los datos dentro de ciertos
límites preestablecidos. Los datos efectivamente codificados facilitan al usuario su introducción pre-
cisa, reduciendo al mínimo la cantidad de datos y por ende, el tiempo requerido para introducirlos.
Cuando los usuarios introducen datos con eficiencia, la entrada cumple con ciertas medidas
predeterminadas de desempeño basadas en la relación entre el tiempo invertido y el número de
datos introducidos. La codificación efectiva, la captura e introducción de datos efectiva y eficiente,
y la acción de asegurar la calidad de los datos por medio de procedimientos de validación son
todos objetivos de entrada de datos que cubriremos en este capítulo.
CODIFICACIÓN EFECTIVA
Una de las formas en que se pueden introducir datos con más precisión y eficiencia es mediante el
empleo informado de varios códigos. Convertir datos ambiguos o voluminosos en dígitos cortos
que se introduzcan con facilidad se denomina codificación (no debemos confundirlo con la escri-
tura de código, o codificación, de programas).
La codificación ayuda al analista de sistemas a alcanzar el objetivo de eficiencia, pues los datos
codificados requieren menos tiempo para que las personas los introduzcan y, por ende, se reduce el nú-
mero de elementos introducidos. La codificación también puede ayudar a ordenar los datos en forma
apropiada en un punto posterior del proceso de transformación de los datos; además pueden ahorrar
valioso espacio de memoria y almacenamiento. En resumen, la codificación es una manera de ser elo-
cuente y a la vez conciso en la captura. Además de proveer precisión y eficiencia, los códigos deben
tener un propósito para apoyar a los usuarios. Los tipos específicos de códigos nos permiten tratar los
datos de una manera específica. Los propósitos humanos para la codificación incluyen lo siguiente:
1. Mantener el registro de algo.
2. Clasificar información.
3. Ocultar información.
P A R T E V
Aseguramiento e
implementación de la
calidadwww.xlibros.com

486 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Código Explicación del código
68506KND7533TVG 99999XXX9999XXX
Abreviatura de la revista
Primeros cinco dígitos del código postal
Primeras tres consonantes del apellido
Cuatro dígitos de la dirección
FIGURA 15.2
Identificación de la cuenta del
suscriptor de una revista mediante
un código de derivación alfabética.
Pedido #
5676 Silla mecedora con piel Arthur Hook, Jr.
5677 Silla de comedor/tapizada Millie Monice
5678 Love Seat/tapizado J. & D. Pare
5679 Silla mecedora para niño/calcomanías Lucinda Morely
Producto Cliente
FIGURA 15.1
Uso de un código de secuencia
simple para indicar la secuencia en
que los pedidos entran a una
tienda de muebles a la medida.
4. Revelar información.
5. Solicitar la acción apropiada.
Hablaremos sobre cada uno de estos propósitos de codificación en las siguientes secciones, junto con algunos
ejemplos de códigos.
Mantener el registro de algo
Algunas veces simplemente queremos identificar una persona, lugar o cosa sólo para llevar un registro. Por ejem-
plo, un taller de muebles a la medida necesita asignar un número de trabajo a un proyecto. El vendedor necesita
conocer el nombre y la dirección del cliente, pero el gerente del taller o los trabajadores que ensamblan los mue-
bles no. En consecuencia, se asigna un número arbitrario al trabajo. El número puede ser aleatorio o secuencial,
como se describe en la siguiente subsección.
CÓDIGOS DE SECUENCIA SIMPLE El código de secuencia simple es un número que se asigna a algo si necesita
estar enumerado. Por lo tanto, no tiene relación con los datos en sí. La figura 15.1 muestra cómo se asigna un
número a los pedidos de un fabricante de muebles. Con este medio de fácil referencia, la empresa puede llevar el
registro del pedido en proceso. Es más eficiente introducir el trabajo “5676” que “esa silla mecedora color café
con negro, con el asiento de piel para Arthur Hook, Jr.”.
Usar un código secuencial en vez de un número aleatorio tiene sus ventajas. En primer lugar, elimina la po-
sibilidad de asignar el mismo número; en segundo, da a los usuarios una aproximación de cuándo se recibió el
pedido.
Hay que usar códigos de secuencia cuando el orden de procesamiento requiera de un conocimiento de la
secuencia en la que los elementos entran al sistema, o el orden en el que se desarrollen los eventos. Podemos en-
contrar un ejemplo en la situación de un banco que ofrece una promoción especial en la que es importante saber
cuándo presentó una persona su solicitud para un préstamo para vivienda especial de bajo interés, ya que (siendo
todos los demás factores iguales) los préstamos hipotecarios especiales se otorgarán según el orden en el que se
hayan presentado las solicitudes. En este caso es importante asignar un código de secuencia correcto a cada so-
licitante.
CÓDIGOS DE DERIVACIÓN ALFABÉTICA A veces no es conveniente usar códigos de secuencia. La situación más
obvia es cuando no deseamos que alguien lea el código para averiguar cuántos números se han asignado; otro
caso es cuando sea conveniente un código más complejo para evitar un costoso error. Un posible error sería
agregar un pago a la cuenta 223 cuando en realidad queríamos agregarlo a la cuenta 224, y todo por introducir el
dígito incorrecto.
El código de derivación alfabética es una metodología común para identificar un número de cuenta. El ejem-
plo de la figura 15.2 proviene de una etiqueta de correo para una revista. El código se convierte en el número de
cuenta. Los primeros cinco dígitos provienen de los primeros cinco dígitos del código postal del suscriptor; los
siguientes tres dígitos son las primeras tres consonantes en el nombre del suscriptor, los siguientes cuatro núme-
ros son de la dirección y los últimos tres representan el código de la revista. El principal propósito de este código
es identificar una cuenta.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 487
Código
P
G
I
C
D
S
Elemento deducible de impuestos
Pagos de intereses
Gastos médicos
Impuestos
Contribuciones
Donaciones
Suministros
FIGURA 15.3
Cómo agrupar los elementos
deducibles de impuestos por
medio de un código de
clasificación de una letra.
Un segundo propósito es el de imprimir etiquetas de correo. Al diseñar este código, el código postal es la
primera parte del número de cuenta. Por lo general, los registros de suscriptores se actualizan sólo una vez al año,
pero el principal propósito de los registros es imprimir etiquetas de correo una vez al mes o una vez por semana. Tener
el código postal como la primera parte del campo de clave primaria significa que los registros no se tienen que
ordenar por código postal para enviarlos en masa, ya que los registros de un archivo se almacenan en secuencia
por clave primaria. Cabe mencionar que la fecha de expiración no es parte del número de cuenta, ya que ese nú-
mero puede cambiar con más frecuencia que los otros datos.
Una desventaja de un código de derivación alfabética ocurre cuando la porción alfabética es pequeña (por
ejemplo, el nombre Po) o cuando el nombre contiene menos consonantes de las que el código requiere. El nom-
bre Roe tiene sólo una consonante y se tendría que derivar como RXX, o por medio de algún otro esquema. Otra
desventaja es que algunos de los datos pueden cambiar. Al modificar la dirección o el nombre de un suscriptor
cambiaría la clave primaria para el archivo.
Clasificar la información
La clasificación ofrece la posibilidad de diferenciar entre las clases de elementos. Las clasificaciones son nece-
sarias para muchos fines, como reflejar las partes del plan de seguro médico con las que cuenta un empleado, o
mostrar cuál estudiante completó los requerimientos básicos de su programa de estudios.
Para que sean útiles, las clases deben ser mutuamente excluyentes. Por ejemplo, si un estudiante está en la
clase F (que significa estudiante de primer año) y completó de 0 a 36 horas crédito, no hay que clasificarlo tam-
bién como estudiante de segundo año (S). Las clases superpuestas serían F 0 36 horas crédito, S 32 64
horas crédito, etcétera. Los datos no son claros y no se pueden interpretar con tanta facilidad cuando las clases de
codificación no son mutuamente excluyentes.
CÓDIGOS DE CLASIFICACIÓN Los códigos de clasificación se utilizan para diferenciar un grupo de datos con
características especiales de otro. Los códigos de clasificación pueden consistir de una sola letra o número. Son
una manera abreviada de describir una persona, un lugar, una cosa o un evento.
Los códigos de clasificación se listan en los manuales o se publican de manera que los usuarios puedan locali-
zarlos con facilidad. Muchas veces los usuarios se familiarizan tanto con los códigos de uso frecuente que los me-
morizan. Un usuario clasifica un elemento y después introduce su código directamente en un sistema en línea.
Un ejemplo de codificación de clasificación es la forma en que sería conveniente agrupar los rubros dedu-
cibles de impuestos para poder llenar una declaración de impuestos. La figura 15.3 muestra cómo se desarrollan
códigos para elementos tales como Pagos de intereses, Gastos médicos, contribuciones, etcétera. El sistema de codi-
ficación es simple: se toma la primera letra de cada una de las categorías; las contribuciones son C, los pagos de
intereses son P y los suministros son S.
Todo marcha bien hasta que llegamos a otras categorías (como elementos de computadora, pagos de seguros
y suscripciones) que empiezan con las mismas letras utilizadas previamente. La figura 15.4 demuestra lo que
ocurre en este caso. Extendimos la codificación de manera que pudiéramos usar P para “ComPutadora”, A para
“PAgos de seguros” y B para “SuBscripciones”. Sin duda esta situación está lejos de ser perfecta. Una manera
de evitar este tipo de confusión es permitir códigos mayores de una letra, lo cual veremos más adelante en este
capítulo bajo el subtítulo de códigos mnemónicos. Los menús desplegables en un sistema de GUI utilizan con
frecuencia códigos de clasificación como método abreviado para seleccionar las características del menú, como
Alt-A para el menú Archivo.
CÓDIGOS DE SECUENCIA EN BLOQUE Anteriormente vimos los códigos de secuencia; el código de secuencia en
bloque es una extensión. La figura 15.5 muestra cómo el usuario de una empresa asigna números al software
de computadora. Las principales categorías de software son navegadores, paquetes de bases de datos y diseño
Web. A estas categorías se les asignaron números secuenciales en los siguientes “bloques” o rangos: navegador,
100-199, base de datos, 200-299, y así en lo sucesivo. La ventaja del código de secuencia en bloque es que los
datos se agrupan de acuerdo con las características comunes, al tiempo que aprovechan la simpleza de asignar el
siguiente número disponible (dentro del bloque, desde luego) al siguiente elemento que necesite identificación.www.xlibros.com

488 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Código Elemento deducible de impuestos
SuBscripciones
ComPutadora
PAgos de seguros
Estos códigos
duplicados...
... se corrigen al
“forzar” los códigos
que se van a usar.
P
G
I
C
D
S
Pagos de intereses
Gastos médicos
Impuestos
Contribuciones
Donaciones
Suministros
S
C
P
G
Subscripciones
Computadora
Pagos de seguros
Gastos varios
B
P
A
FIGURA 15.4
Los problemas al usar un código
de clasificación de una letra
ocurren cuando las categorías
comparten la misma letra.
Código Nombre del paquete de software Tipo
100
101
102
200
201
202
300
301
302
Apple Safari
Mozilla Firefox
Microsoft Internet Explorer
Microsoft Access
MySQL
Oracle
Adobe Dreamweaver
Freeway Pro
Microsoft Web Expression
Navegador
Base de datos
Diseño Web
.
.
.
.
.
.
FIGURA 15.5
Uso de un código de secuencia en
bloque para agrupar paquetes de
software similares.
Ocultar información
Podemos usar códigos para ocultar o disfrazar la información que otras personas no deban conocer. Hay muchas
razones por las que una empresa podría querer hacer esto. Por ejemplo, tal vez una corporación no desee que los
empleados capturistas de datos accedan a la información en un archivo de personal. Tal vez una tienda quiera que
sus vendedores conozcan el precio de mayoreo para mostrarles cuál es el precio más bajo que puedan negociar,
pero podría codificarlo en las etiquetas de los precios para evitar que los clientes lo descubran. Tal vez un restaurante
quiera capturar la información sobre el servicio sin dejar que el cliente sepa el nombre del mesero. El oculta-
miento de la información y la seguridad se han convertido en temas muy importantes durante los últimos años.
Las corporaciones han empezado a permitir a los distribuidores y consumidores el acceso directo a sus bases de
datos, y el hecho de manejar las transacciones comerciales a través de Internet ha provocado que sea necesario
desarrollar estrictos esquemas de cifrado. En la siguiente subsección veremos un ejemplo de cómo ocultar infor-
mación por medio de códigos.
CÓDIGOS DE CIFRADO Tal vez el método de codificación más simple sea la sustitución directa de una letra por
otra, un número por otro o una letra por un número. Como ejemplo de sustitución de letras podríamos mencionar
un tipo popular de acertijo conocido como criptograma. La figura 15.6 muestra un ejemplo de un código de
cifrado tomado de una tienda de departamentos de Buffalo, Nueva York, la cual codificó todos los precios
rebajados con las palabras BLEACH MIND. Nadie recordó realmente por qué se eligieron estas palabras, pero
todos los empleados las conocían de corazón y eso contribuyó al éxito del código de cifrado. Podemos observar
en esa figura que un artículo con un precio de venta de $25.00 podría tener un precio rebajado de BIMC, o de
$18.75 cuando se decodifica letra por letra.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 489
Código Significado Ejemplo de la etiqueta de precio Explicación
B 1 GOLDEN’S Nombre de la tienda
L 2 202-395-40 Código de estilo
E 3 BIMC Precio rebajado codificado
A 4
C 5
H 6 Talla 12 Tamaño de la ropa
M 7
I 8 $25.00 Precio del cliente
N 9
D 0
Precio regular del vestido = $25.00
BIMC codificado de la etiqueta de rebaja = $18.75
FIGURA 15.6
Codificar los precios rebajados
mediante un código de cifrado es
una forma de ocultar la
información de los precios a los
clientes.
Revelar información
Algunas veces es conveniente revelar información a usuarios específicos por medio de un código. En una tienda
de ropa, la información sobre el departamento, producto, color y tamaño se imprime junto con el precio en el re-
cibo para cada artículo. Esta información ayuda a los vendedores y al personal de existencias a localizar el lugar
para la mercancía.
Otra razón de revelar información por medio de códigos es para que la entrada de datos sea más significativa
para los humanos. Un número de pieza, nombre o descripción familiares producen una mayor entrada de datos.
Los ejemplos de los códigos en la siguiente subsección explican cómo se pueden llevar a cabo estos conceptos.
2023954010 202 395 40 10
Código Mercancía descrita Explicación del código
Talla
(Talla 12)
Talla
(Talla 10)
Color
(Beige)
Color
(Rojo)
Producto
(Abrigo estilo 219)
Producto
(Vestido estilo 395)
Departamento
(Abrigos de invierno)
Departamento
(Maternidad)
414 219 19 12
Vestido de maternidad
rojo, estilo 385, talla 10
Abrigo de invierno color
beige, estilo 219, talla 12
4142191912
FIGURA 15.7
El uso de un código de
subconjunto de dígitos
significativos ayuda a los
empleados a localizar
los artículos que corresponden
a un departamento específico.www.xlibros.com

490 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Hospitales de la ciudad
BGH Buffalo General Hospital
ROS Roswell Park Memorial Institute
KEN Kenmore Mercy
DEA Deaconess Hospital
SIS Sisters of Charity
STF Saint Francis Hospital
STJ Saint Joseph’s Hospital
OLV Our Lady of Victory Hospital
Código
FIGURA 15.8
Los códigos mnemónicos
funcionan como ayudas de
memoria mediante el uso de una
combinación significativa de letras
y números.
CÓDIGOS DE SUBCONJUNTO DE DÍGITOS SIGNIFICATIVOS Cuando es posible describir un producto en virtud de
su membresía en varios subgrupos, podemos usar un código de subconjunto de dígitos significativos para ayudar
a describirlo. El ejemplo de la etiqueta de precios de la tienda de ropa en la figura 15.7 es un ejemplo efectivo de
un código de subconjunto de dígitos significativos.
Para el cliente o espectador casual, la descripción del artículo parece ser un largo número; para los vendedo-
res, el número está formado de varios números más pequeños, cada uno de los cuales tiene su propio significado.
Los primeros tres dígitos representan el departamento, los siguientes tres el producto, los siguientes dos el color
y los últimos dos el tamaño.
Los códigos de subconjunto de dígitos significativos pueden consistir de la información que describe real-
mente al producto (por ejemplo, el número 10 representa a la talla 10) o de números que se asignan en forma
arbitraria (por ejemplo, se asigna un 202 para indicar el departamento de maternidad). En este caso, la ventaja de
usar un código de subconjunto de dígitos significativos es que es posible localizar los artículos que pertenecen a
cierto grupo o clase. Por ejemplo, si el gerente de la tienda decidió rebajar toda la mercancía de invierno para una
venta próxima, los vendedores podrían localizar todos los artículos que pertenezcan a los departamentos del 310
al 449, el bloque de códigos que se utilizan para designar “invierno” en general.
CÓDIGOS MNEMÓNICOS Un mnemónico es una ayuda para la memoria humana. Se considera mnemónico
cualquier código que ayuda a una persona a introducir los datos o a un usuario a recordar cómo usar la
información. Al utilizar una combinación de letras y símbolos obtenemos una manera muy clara de codificar un
producto, de tal forma que el código se pueda ver y comprender con facilidad.
Los códigos de hospitales de la ciudad utilizados por el Banco de Sangre Regional de Buffalo eran mnemó-
nicos, como se muestra en la figura 15.8. Los códigos simples se inventaron precisamente debido a que los admi-
nistradores y analistas de sistemas del banco de sangre querían asegurar que los códigos de los hospitales fueran
fáciles de memorizar y recordar. Los códigos mnemónicos para los hospitales ayudaron a reducir la posibilidad
de enviar sangre al hospital incorrecto.
Unicode
Los códigos nos permiten revelar caracteres que por lo general no podemos introducir o ver. Los teclados tradi-
cionales proporcionan conjuntos de caracteres conocidos para las personas que utilizan caracteres alfabéticos oc-
cidentales (conocidos como caracteres del latín), pero muchos lenguajes como el griego, japonés, chino o hebreo
no utilizan el alfabeto occidental. Estos lenguajes pueden usar letras griegas, glifos o símbolos que representan
sílabas o palabras completas. La Organización Internacional para la Estandarización (ISO) definió el conjunto de
caracteres Unicode, el cual incluye todos los símbolos de lenguajes estándar y tiene espacio para 65,535 carac-
teres. Podemos mostrar páginas Web escritas en otros alfabetos si descargamos un editor de métodos de entrada
de Microsoft.
Los símbolos de glifos se representan mediante una notación “&#xnnnn;”, en la que nnnn representa a una
letra o símbolo específico y x significa que se utiliza la notación hexadecimal, o numeración base 16, para re-
presentar los caracteres Unicode. Por ejemplo, &#30B3 representa el símbolo ko en japonés katakana. El código
que se utiliza para la palabra japonesa hola, konichiwa, es こにち&#x308F. En japonés,
la palabra se ve así:
El conjunto completo de caracteres Unicode se agrupa por lenguaje; puede encontrarlo en www.unicode.org.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 491
Código Función
1
2
3
4
5
6
7
8
9
Entregado
Vendido
Echado a perder
Perdido o robado
Devuelto
Enviado por transferencia
Recibido por transferencia
Entrada en el diario (Sumar)
Entrada en el diario (Restar)
FIGURA 15.9
Los códigos de función capturan
en forma compacta las funciones
que debe realizar la computadora.
Solicitar la acción apropiada
A menudo se requieren códigos para instruir a la computadora o al encargado de tomar decisiones sobre la ac-
ción que deben tomar. Por lo general, dichos códigos se conocen como códigos de función y comúnmente toman
la forma de códigos de secuencia o mnemónicos.
CÓDIGOS DE FUNCIÓN Las funciones, que el analista o programador desea que la computadora realice con los
datos, se capturan en códigos de función. La acción de explicar con detalle las actividades a realizar se traduce
en un código corto numérico o alfanumérico.
La figura 15.9 muestra ejemplos de un código de función para actualizar el inventario. Suponga que admi-
nistra un departamento de productos lácteos; si se echara a perder una caja de yogurt, utilizaría el código 3 para
indicar este evento. Desde luego que los datos requeridos para la entrada dependen de la función que se necesite.
Por ejemplo, para adjuntar datos a un registro o actualizarlo se requeriría sólo la clave del registro y al código de
función, mientras que para agregar un registro habría que introducir todos los elementos de datos, incluyendo el
código de función.
Lineamientos generales para la codificación
En las secciones anteriores examinamos los propósitos de usar distintos tipos de códigos cuando los humanos y
las máquinas introducen y almacenan datos. A continuación examinaremos unas cuantas heurísticas para estable-
cer un sistema de codificación. En la figura 15.10 se resaltan estas reglas.
SEA CONCISO Los códigos deben ser concisos. Los códigos demasiado extensos requieren más pulsaciones
de tecla y, en consecuencia, puede haber más errores. Los códigos extensos también implican que el proceso de
almacenar la información en una base de datos requerirá más memoria.
Los códigos cortos son más fáciles de recordar para las personas y más fáciles de introducir que los códi-
gos extensos. Si hay que usar códigos extensos, sería conveniente descomponerlos en sub-códigos. Por ejemplo,
5678923453127 se podría descomponer mediante guiones de la siguiente manera: 5678-923-453-127. Esta
metodología es mucho más manejable y aprovecha la forma en que sabemos que las personas procesan la infor-
mación: en trozos pequeños. Algunas veces, los códigos se hacen más extensos de lo necesario por alguna razón.
En general los números de tarjetas de crédito son extensos para evitar que las personas adivinen el número de
una tarjeta de crédito. Visa y MasterCard utilizan números de 16 dígitos; esto permite generar números exclusi-
vos para nueve billones de personas. Como los números no se asignan en forma secuencial, las probabilidades de
adivinar el número de una tarjeta de crédito son muy pocas.
Para establecer un sistema de
codificación, el analista debe:
Mantener los códigos concisos
Mantener los códigos estables
Crear códigos únicos
Permitir ordenar los códigos
Evitar códigos confusos
Mantener los códigos uniformes
Permitir modificar los códigos
Que los códigos sean significativos
FIGURA 15.10
Hay ocho lineamientos generales
para establecer un sistema de
codificación.www.xlibros.com

492 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U L T O R Í A 1 5 . 1
Aquí parece una jungla
“No puedo soportar esto. He estado buscando este sombrero
durante los últimos 45 minutos”, se queja Davey mientras balancea
una gorra de mapache agarrándola por la cola y pasándola sobre su
cabeza. Él es uno de los nuevos trabajadores del almacén para
Crokett’s, una gran empresa de ventas por catálogo y comercio
electrónico. “La hoja del catálogo la llama ‘Coo m5-9w/t’. Lo
bueno fue que me dijiste que ‘Coo’ representa la palabra mapache.
Después, claro está, pensé en las gorras y busqué por aquí. La en-
contré aquí, en este bote etiquetado como NIÑOS/GORRA. ¿No
sería más fácil si el catálogo y las páginas Web coincidieran con los
botes? Para mí, esta factura dice: “Utensilios de cocina metálicos,
conjunto de 5-9 piezas con Teflón’. He estado varado en los conjun-
tos de cocina todo el tiempo”.
Daniel, uno de sus compañeros, apenas si lo escucha mientras
saca apurado artículos de los botes para surtir otro pedido. “Te acos-
tumbrarás a esto. Deben tenerlo de esta manera para que las computa-
doras puedan entender la factura después. La mayor parte del tiempo
busco el número de la página del catálogo en la factura, después lo
busco en el libro y hago algo así como una traducción de vuelta acá...
a menos que recuerde haberlo encontrado antes”, explica Daniel.
Davey se empeña en decir: “Pero las computadoras son inteli-
gentes y tenemos que surtir demasiados pedidos. Podríamos decir a
los de facturación los nombres que tenemos en nuestros botes”.
Daniel responde con cinismo: “Sí, claro. Se están muriendo
por saber nuestra opinión”. Después continúa con un tono más
calmado: “Sabes, solíamos tenerlo así, pero cuando llegaron las
nuevas computadoras y pasamos a los pedidos telefónicos las 24
horas y a través de Internet, todo cambió. Dijeron que los operado-
res (y usuarios) tenían que saber más sobre lo que estaban ven-
diendo (o comprando), por lo que cambiaron sus códigos para que
fueran más como una historia”.
Davey, sorprendido de la revelación de Daniel, pregunta:
“¿Cuál es la historia del código con el que he estado trabajando?”.
Después de inspeccionar el código en la factura de la gorra,
Daniel responde: “El código con el que estabas trabajando era ‘Coo
m5-9w/tl’. Después de buscarlo con una rapidez increíble en la
computadora, el operador puede decir al cliente: ‘Es una gorra de
mapache (Coo) para niños (m de masculino) con edades de 5 a 9,
con una cola real (w/tl)’. Los árboles no nos dejan ver el bosque
debido a sus códigos, pero ya sabe como son en Crockett’s. Tienen
que lograr la venta”.
¿Qué tan importante es el hecho de que los botes y las facturas
del almacén se codifiquen en forma inconsistente? Responda en un
párrafo. ¿Cuáles son algunos de los problemas que surgen cuando
un código parece ser mnemónico pero los empleados nunca reciben
una “clave” apropiada para decodificarlo? Describa su respuesta en
dos párrafos. ¿Qué cambios realizaría en la codificación de las factu-
ras/el almacén para Crockett’s? Documente sus cambios, identifique
el tipo de código que usaría y use el código en un ejemplo de un producto
que se podría vender en Crockett’s. Recuerde descifrarlo también.
MANTENER LOS CÓDIGOS ESTABLES Estabilidad significa que el código de identificación para un cliente no debe
cambiar cada vez que se reciban nuevos datos. Anteriormente presentamos un código de derivación alfabética
para la lista de suscriptores de una revista. La fecha de expiración no formaba parte del código de identificación
del suscriptor debido a que es probable que vaya a cambiar.
No cambie las abreviaturas de código en un sistema mnemónico. Una vez que haya elegido las abreviaturas
del código, no trate de modificarlas ya que será muy difícil que el personal de captura de datos se adapte.
ASEGURAR QUE LOS CÓDIGOS SEAN ÚNICOS Para que los códigos funcionen, deben ser únicos. Tome nota de
todos los códigos utilizados en el sistema para asegurar que no vaya a asignar el mismo número de código o
nombre a los mismos artículos. Los números de código y los nombres son una parte esencial de las entradas en
los diccionarios de datos, como vimos en el capítulo 8.
PERMITIR ORDENAR LOS CÓDIGOS Si va a manipular los datos en forma útil, los códigos deben poder ordenarse.
Por ejemplo, si desea realizar una búsqueda de texto en los meses del año en orden ascendente, los meses que
empiezan con “J” estarían fuera de orden (Julio y después Junio). Los diccionarios se ordenan de esta manera,
una letra a la vez y de izquierda a derecha. Por lo tanto, si ordenara en base a MMMDDAAAA, en donde MMM
representa el mes, DD el día y AAAA el año, el resultado sería incorrecto.
La figura 15.11 muestra lo que ocurriría si se realizara una búsqueda de texto en distintos formatos de fecha.
La tercera columna muestra un problema que formaba parte de la crisis del año 2000 (Y2K) que provocó cierto
grado de alarma e incluso apareció en la portada de la revista Time.
Una de las lecciones aprendidas es que debemos asegurarnos de que los usuarios puedan hacer lo que que-
ríamos que hicieran con los códigos que creamos. Es mucho más fácil ordenar códigos numéricos que los alfanu-
méricos; por lo tanto, considere la opción de convertir los códigos a numéricos siempre que sea práctico.
EVITAR CÓDIGOS CONFUSOS Trate de evitar el uso de caracteres de codificación que se vean o suenen igual.
Los caracteres O (la letra o) y 0 (el número cero) se confunden con facilidad, al igual que la letra I y el número
1, y también la letra Z y el número 2. Por ello, los códigos tales como B1C y 280Z no son satisfactorios.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 493
Orden incorrecto
al usar
MMM-DD-AAAA
Orden incorrecto
al usar
MM-DD-AAAA
Orden incorrecto
(problema del año
2000) AA-MM-DD
Orden correcto
al usar
AAAA-MM-DD
Dic-25-1998
Dic-31-1997
Jul-04-1999
Jun-04-1998
Jun-11-2000
Jun-12-1997
Oct-24-1998
06-04-1998
06-11-2000
06-12-1997
07-04-1999
10-24-1998
12-25-1998
12-31-1997
00-06-11
97-06-12
97-12-31
98-06-04
98-10-24
98-12-25
99-07-04
1997-06-12
1997-12-31
1998-06-04
1998-10-24
1998-12-25
1999-07-04
2000-06-11
FIGURA 15.11
Planifique para poder hacer algo
útil con los datos que se hayan
introducido. En este ejemplo, la
persona que creó los códigos no
tomó en cuenta que se tendrían
que ordenar.
Un ejemplo de un código potencialmente confuso es el Código Postal Canadiense, como se muestra en la
figura 15.12. El formato del código es X9X 9X9, en donde X representa una letra y 9 representa un número. Una
ventaja de usar letras en el código es que se permiten más datos en un código de seis dígitos (hay 26 letras y
sólo 10 números). Como los canadienses utilizan el código con regularidad, tiene mucho sentido para ellos. Sin
embargo, para los extranjeros que envían correo a Canadá puede ser muy difícil saber si el penúltimo símbolo es
una Z o un 2.
MANTENER LOS CÓDIGOS UNIFORMES Para que sean efectivos y eficientes para los humanos, los códigos
necesitan conformarse a formas que se perciban rápidamente la mayor parte del tiempo. Los códigos que se usan
en conjunto, como BUF-234 y KU-3456, son malos debido a que el primero contiene tres letras y tres números,
mientras que el segundo sólo tiene dos letras seguidas de cuatro números.
Cuando tenga que agregar fechas, trate de evitar usar los códigos MMDDAAAA en una aplicación,
AAAADDMM en otra aplicación y MMDDAA en una tercera aplicación. Es importante mantener la uniformi-
dad en los códigos, así como dentro de los programas.
PERMITIR LA MODIFICACIÓN DE LOS CÓDIGOS. La capacidad de adaptación es una característica clave de un
buen código. El analista debe tener en cuenta que el sistema evolucionará con el tiempo, por lo que el sistema de
codificación debe ser capaz de abarcar el cambio. El número de clientes debe aumentar, los clientes cambiarán
de nombres y los proveedores modificarán la forma en que enumeran sus productos. El analista debe ser capaz de
pronosticar los cambios predecibles que los usuarios de la empresa deseen; además se debe anticipar a un amplio
rango de necesidades a futuro a la hora de diseñar los códigos.
HACER LOS CÓDIGOS SIGNIFICATIVOS A menos que el analista dese ocultar información de manera intencional,
los códigos deben ser significativos. Los códigos efectivos no sólo contienen información; también tienen mucho
sentido para las personas que los utilizan. Los códigos significativos son fáciles de entender y recordar; también
es muy fácil trabajar con ellos. El trabajo de capturar los datos se vuelve más interesante cuando se trabaja con
códigos significativos en vez de introducir sólo una serie de números sin significado.
USAR LOS CÓDIGOS Podemos usar los códigos de varias formas. En los programas de validación, los datos de
entrada se comparan con una lista de códigos para asegurar que sólo se hayan introducido códigos válidos. En
los programas de informes y consultas, un código almacenado en un archivo se transforma en el significado del
código. Los informes y las pantallas no deben mostrar o imprimir el código real. Si lo hicieran, el usuario tendría
que memorizar los significados del código o buscarlos en un manual. Los códigos se utilizan en los programas de
GUI para crear listas desplegables.
Código manuscrito Código real Ciudad, Provincia Problema
L8S 4M4
T3A ZE5
LOS 1JO
L8S 4M4
T3A 2E5
L0S 1J0
Hamilton, Ontario
Calgary, Alberta
Niagara-on-the-Lake,
Ontario
La S parece un 5
El 2 parece una Z
El 5 parece una S
El cero y la o se ven casi idénticos
La S parece un 5
El 1 parece una I
Formato de código para el Código Postal Canadiense
X9X 9X9
FIGURA 15.12
Combinar caracteres similares en
los códigos puede provocar
errores.www.xlibros.com

494 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
CAPTURA DE DATOS EFECTIVA Y EFICIENTE
Para asegurar la calidad de los datos que los usuarios introducen al sistema, es importante capturar los datos con
efectividad. La captura de datos ha recibido cada vez más atención como el punto en el procesamiento de la in-
formación en el que se pueden obtener excelentes ganancias en productividad. El proceso de capturar datos ha
mejorado de manera considerable en las últimas cuatro décadas, a medida que avanzamos de los sistemas de va-
rios pasos, lentos y propensos a errores como las tarjetas perforadas, hasta el uso de sistemas sofisticados como
el reconocimiento de caracteres (OCR), los códigos de barras y las terminales de punto de venta.
Qué capturar
La decisión sobre lo que se debe capturar es más importante que la interacción del usuario con el sistema. En
definitiva es imprescindible para hacer que la interfaz final valga la pena, dado que aún es válido el adagio
“entra basura, sale basura”.
Los analistas de sistemas y los usuarios son los que se encargan de las decisiones sobre los datos que se
deben capturar para introducirlos al sistema. Gran parte de lo que se captura es específico para la empresa en
particular. Capturar datos, introducirlos, almacenarlos y recuperarlos son todos procesos costosos. Con todos es-
tos factores en mente, determinar qué es lo que se debe capturar se convierte en una decisión importante.
Hay dos tipos de datos a introducir: los datos que cambian o varían con cada transacción y los datos que
diferencian en forma concisa el elemento específico que se está procesando de los demás elementos.
Un ejemplo de datos que se pueden modificar es la cantidad de provisiones que se compran cada vez que
una empresa de publicidad coloca un pedido con el mayorista de artículos de oficina. Como las cantidades
cambian dependiendo del número de empleados en la empresa de publicidad y de cuántas cuentas estén mane-
jando, hay que introducir datos sobre la cantidad cada vez que se coloca un pedido.
Un ejemplo de datos de diferenciación es incluir el número de Seguro Social y las primeras tres letras del
nombre de un/una paciente en su registro. De esta manera, el/la paciente se diferencia en forma única de los
demás pacientes en el mismo sistema.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 5 . 2
Pescar un código de verano
Vicky retira los dedos del teclado y se inclina en su estación de
trabajo para verificar las letras de las facturas apiladas en frente de ella.
“¡Qué diantres!”, Vicky pregunta en voz alta mientras escudriña las
letras que codifican las ciudades a donde se van a enviar los pedidos.
Shelly Overseer, su supervisora, que por lo general se sienta a
un par de estaciones de trabajo de distancia, pasa por ahí y ve la
consternación de Vicky. “¿Cuál es el problema? ¿Acaso olvidaron los
representantes de ventas escribir el código de la ciudad otra vez?”.
Vicky gira en su silla para ver a Shelly de frente. “No, los có-
digos están aquí, pero están raros. Por lo general utilizamos un
código de tres letras, ¿verdad? Como CIN para Cincinnati, SEA
para Seattle, MIN para Minneapolis, BUF para Buffalo. Pero aquí
hay sólo códigos de cinco letras”.
“Mira”, dice Vicky mientras levanta la factura para mostrarla
a Shelly. “CINNC, SEATT, MINNE. Me tomará todo el día intro-
ducir estos códigos. En serio, me estoy tardando mucho. Tal vez
haya un error. ¿No puedo simplemente usar el estándar?”.
Shelly retrocede de la estación de trabajo de Vicky como si el
problema fuera contagioso. Se disculpa y dice: “Son los de medio
tiempo. Están aprendiendo sobre ventas ahora, y a la gerencia le
preocupaba que hicieran un desorden con sus ciudades. Creo que
tiene algo que ver con haber mezclado Newark y Nueva Orleans en
los últimos pedidos. Por lo tanto, un comité decidió agregar dos
letras para que las ciudades se pudieran reconocer con más facili-
dad. Esos chicos no pueden aprender todo lo que sabemos en una
noche, incluso cuando lo intentan. Pero es sólo hasta agosto 19,
cuando los empleados de medio tiempo regresan a la escuela.
Mientras Vicky regresa con desánimo a su teclado, Shelly sa-
cude su cabeza con compasión y dice: “Se que es estresante y que
te sientes miserable, pero no te preocupes. Ya se te pasará. Es sólo
un código de verano”.
¿Qué lineamientos generales de codificación ha pasado por
alto la gerencia en su decisión de usar un código de verano para las
ciudades? Haga una lista. ¿Cuál es el efecto sobre el personal de
captura de datos de tiempo completo al cambiar los códigos para
facilitar el trabajo al personal de ayuda temporal? Responda en dos
párrafos. ¿Qué impacto a futuro podría tener el cambio temporal en
los códigos en cuanto a ordenar y recuperar los datos introducidos
durante el periodo de verano? Describa en dos párrafos estas impli-
caciones. ¿Qué cambios puede usted sugerir de manera que los
empleados de medio tiempo no se confundan con los códigos a
corto plazo? En un memo para el supervisor de este grupo de tra-
bajo, haga una lista de cinco a siete cambios en los procedimientos
de captura o introducción de datos que se puedan realizar para
adaptarse a las contrataciones de corto plazo sin perturbar las acti-
vidades comerciales regulares. Indique en un párrafo cómo se
puede lograr esta meta sin comprometer la productividad del perso-
nal que introduce los datos.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 495
Dejar que la computadora haga el resto
Al considerar qué datos es necesario capturar para cada transacción y qué datos hay que dejar para que el sistema
los introduzca, el analista de sistemas debe aprovechar lo que las computadoras hacen mejor. En el anterior ejem-
plo de la agencia de publicidad y el pedido de artículos de oficina, no es necesario que el operador que introduce
el pedido de papelería vuelva a capturar la descripción de cada artículo siempre que se reciba un pedido. La compu-
tadora puede almacenar y acceder a esta información con facilidad.
Las computadoras pueden manejar de manera automática las tareas repetitivas, como registrar el tiempo de la
transacción, calcular nuevos valores a partir de la entrada, además de almacenar y recuperar datos bajo demanda. Al
emplear las mejores características de las computadoras, el diseño de la captura de datos eficiente evita la entrada
de datos innecesarios, que a su vez alivia muchos de los errores humanos y el aburrimiento, además de que permite
a las personas concentrarse en tareas creativas o de más alto nivel. Podemos escribir software para pedir al usuario
que introduzca la fecha de hoy o capturar la fecha del reloj interno de la computadora. Una vez introducido este
dato, el sistema procede a usar esa fecha en todas las transacciones procesadas en esa sesión de entrada de datos.
Un ejemplo de primera sobre reutilización de datos que se introducen una vez es el del centro de bibliotecas
de cómputo en línea (OCLC) que utilizan miles de bibliotecas en los Estados Unidos. OCLC se creó a partir de
la idea de que cada elemento comprado por una biblioteca sólo debería catalogarse una vez en toda su vida. Des-
pués de introducir un elemento, la información de clasificación va a la enorme base de datos de OCLC y se com-
parte con las bibliotecas participantes. En este caso, la implementación del concepto simple de introducir datos
sólo una vez ahorra una enorme cantidad de tiempo al introducir los datos.
También hay que tener en cuenta el poder de cálculo de la computadora al decidir qué no debemos volver a
introducir. Las computadoras son adeptas a los cálculos extensos, en los que se utilizan datos que ya se introdu-
jeron antes.
Por ejemplo, la persona que introduce los datos puede introducir los números de vuelo y el número de cuenta
de un viaje aéreo realizado por un cliente que pertenezca a un programa de incentivos para viajeros frecuentes.
Después, la computadora calcula el número de millas acumuladas para cada vuelo, lo agrega a las millas que ya
están en la cuenta del cliente y actualiza el total de millas acumuladas en la cuenta. La computadora también
puede marcar una cuenta que, en virtud de la gran cantidad de millas acumuladas, sea elegible para un premio.
Aunque toda esta información puede aparecer en la cuenta actualizada del cliente, los únicos datos nuevos intro-
ducidos fueron los números de los vuelos.
En sistemas que utilizan una interfaz gráfica de usuario (GUI), a menudo los códigos se almacenan como
una función o como una tabla separada en la base de datos. Hay desventajas al crear demasiadas tablas, ya que
el software debe buscar los registros que coincidan de cada tabla, lo cual podría ocasionar un acceso lento. Si los
códigos son relativamente estables y cambian con poca frecuencia, tal vez se puedan almacenar como una fun-
ción de la base de datos. Si los códigos cambian con frecuencia, se almacenan en una tabla para que se puedan
actualizar con facilidad.
La figura 15.13 muestra cómo se utiliza una lista desplegable para seleccionar los códigos para agregar o
modificar un registro en la tabla CLIENTE (CUSTOMER). Cabe mencionar que el código está almacenado, pero
FIGURA 15.13
Uso de una tabla de códigos en
una lista desplegable. Esta lista se
utiliza para seleccionar un código
para agregar o modificar un
elemento en un registro.www.xlibros.com

496 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
la lista desplegable muestra tanto el código como su significado. Este método ayuda a asegurar la precisión, ya
que el usuario no tiene que adivinar el significado del código y no hay probabilidad de que escriba uno inválido.
Cómo evitar cuellos de botella y pasos adicionales
En la terminología relacionada con la entrada de datos, un cuello de botella describe gráficamente el efecto del
angostamiento de la botella en el flujo del contenido: los datos se vierten con rapidez en la amplia boca del sistema,
sólo para desacelerar drásticamente en su “cuello” debido a la incapacidad del sistema para procesar el volumen
o detalle de los datos que se están introduciendo. Una manera en la que podemos evitar un cuello de botella es
asegurarnos que haya la capacidad suficiente para manejar los datos que se están introduciendo.
Las formas de evitar los pasos adicionales se determinan no sólo durante el análisis, sino también cuando los
usuarios empiezan a interactuar con los prototipos del sistema. Entre menos pasos se requieran para introducir
datos, menor será la probabilidad de introducir errores. Por lo tanto, además del ahorrar en mano de obra, el he-
cho de evitar pasos adicionales también es una forma de preservar la calidad de los datos. Una vez más, usar un
sistema en tiempo real en línea que capture los datos de los clientes sin necesitar la complejidad de un formulario
es un excelente ejemplo de cómo ahorrar pasos en el proceso de entrada de datos.
Empezar con un buen formulario
Podremos lograr una captura de datos efectiva sólo si consideramos con anticipación lo que debe contener el
documento de origen. El operador introduce los datos del documento de origen (que por lo general es un tipo de
formulario); este documento es la fuente de una gran cantidad de todos los datos del sistema. Los sistemas en lí-
nea (o los métodos especiales de entrada de datos, como los códigos de barras) pueden sortear la necesidad de un
documento de origen, pero es común crear de todas formas algún tipo de formulario en papel, como un recibo.
Cuando se cuenta con formularios efectivos, no es necesario volver a introducir la información que la compu-
tadora ya haya almacenado, ni datos como la fecha y la hora que la computadora puede determinar de manera
automática. En el capítulo 11 vimos con detalle cómo debemos diseñar un formulario o documento de origen
para maximizar su utilidad para capturar datos y minimizar el tiempo que necesitan invertir los usuarios para in-
troducir datos a partir de ese formulario o documento.
Elegir un método de entrada de datos
Hay varios métodos eficientes de entrada de datos disponibles; para elegir uno de ellos hay que tener en cuenta
diversos factores, incluyendo la necesidad de velocidad, precisión y capacitación de los usuarios; el costo del
método de entrada de datos (si requiere de muchos materiales o de mucha mano de obra); y los métodos que se
están usando actualmente en la organización.
TECLADOS El teclado es el método más antiguo de entrada de datos; sin duda es con el que los miembros de las
organizaciones están más familiarizados. Se han realizado algunas mejoras en los teclados con el paso de los años.
Las características más recientes incluyen teclas de función especial para abrir programas, teclas que se utilizan
para desplazarse por las pantallas y explorar la Web, y teclas que se pueden programar con macros para reducir
el número de pulsaciones de teclas requeridas. Los teclados ergonómicos e infrarrojos, junto con los teclados y
ratones habilitados con Bluetooth, son también mejoras considerables.
RECONOCIMIENTO ÓPTICO DE CARACTERES El reconocimiento óptico de caracteres (OCR) permite a un usuario
leer la entrada desde un documento de origen mediante un escáner óptico en vez de usar los medios magnéticos
que hemos visto hasta ahora. El uso de dispositivos OCR puede agilizar la entrada de datos de un 60 a un 90 por
ciento, en comparación con algunos métodos de tecleo.
El aumento en la velocidad del OCR se debe a que no hay que codificar ni teclear los datos que provienen de los
documentos de origen. Esto elimina muchos de los pasos que se requieren en otros dispositivos de entrada en
los que se consume mucho tiempo y puede haber muchos errores. El método del OCR demanda pocas habilida-
des del empleado, lo que significa que su capacitación no tiene que ser muy especializada; esto resulta en menos
errores y menos tiempo invertido por los empleados en esfuerzos redundantes. Además, descentraliza la respon-
sabilidad de obtener datos de calidad para asignarla directamente a la unidad que los está generando. El OCR,
que ahora está disponible para todos, tiene un uso adicional y muy práctico: transformar los faxes en documentos que
se puedan editar.
OTROS MÉTODOS DE ENTRADA DE DATOS Hay otros métodos de entrada de datos que se están empleando cada
vez con más frecuencia. La mayoría de estos métodos reducen los costos de mano de obra al requerir menos
habilidades del operador o poca capacitación, acercan cada vez más el proceso de entrada de datos a su origen
y eliminan la necesidad de un documento de origen. Al hacer esto se han convertido en métodos de entrada de
datos veloces y muy confiables. Los métodos de entrada de datos que veremos en las siguientes subsecciones
incluyen el reconocimiento de caracteres de tinta magnética, los formularios de detección de marcas, los
formularios perforados y las tiras de datos.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 497
Reconocimiento de caracteres de tinta magnética Los caracteres de tinta magnética se encuentran en la parte
inferior de los cheques bancarios y algunas facturas de tarjetas de crédito. Este método es similar al OCR
en cuanto a que se leen caracteres especiales, pero su uso es limitado. La entrada de datos por medio del
reconocimiento de caracteres de tinta magnética (MICR) se realiza a través de una máquina que lee e interpreta
una sola línea de material codificado con tinta formada de partículas magnéticas.
Algunas ventajas del uso de MICR son: 1) es un método confiable y de alta velocidad que no es susceptible
a confundir las marcas fuera de lugar, ya que no están codificadas en forma magnética; 2) si se requiere en todos
los cheques para retirar fondos, sirve como una medida de seguridad contra los cheques falsos, y 3) el personal
de entrada de datos puede ver los números que componen el código, si es necesario verificarlo.
Formularios de detección de marcas Estos formularios permiten introducir datos por medio de un escáner que
detecta en dónde se hicieron las marcas en formularios especiales. Un uso común es para calificar las hojas de
respuestas de los cuestionarios a las encuestas, como se muestra en la figura 15.14. El personal requiere de una
capacitación muy básica; además se puede procesar un alto volumen de formularios con rapidez.
INDICACIONES PARA MARCAR
Haga marcas gruesas de color negro que llenen el círculo por completo.
Borre limpiamente cualquier respuesta que desee cambiar —no raye en ningún otro lado.
Ejemplos de marcas CORRECTAS Ejemplos de marcas INCORRECTAS
1. ¿Qué niveles de personas atiende usted principalmente en su trabajo?
gerentes
supervisores; capataces
otros empleados asalariados
por horas
voluntarios
2. Tamaño total de la organización que usted atiende
menos de 1,000 15,000–25,000
1,000–5,000 más de 25,000
5,000–15,000
3. ¿Qué capacitación y técnicas de desarrollo
utiliza? (Por favor marque cada técnica)
conferencia con o sin medios
películas
TV de circuito cerrado con videocinta
discusiones (casos, cuestiones, etc.)
desempeñar roles
modelado del comportamiento
simulación; juegos avanzados
capacitación en el trabajo
rotación de empleos
prácticas profesionales; ayudantías
técnicas de desarrollo organizacional
otras
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
5. La parte más considerable
4. Una parte importante
3. Una parte substancial
2. Una parte más pequeña
1. Una parte menor
0. No aplica
FIGURA 15.14
Un formulario de detección de
marcas que se puede leer mediante
un escáner agiliza el proceso de
entrada de datos.www.xlibros.com

498 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Una desventaja de los formularios de detección de marcas es que, aunque los lectores pueden determinar si
se hizo una marca, no pueden interpretarla de la manera en que lo hacen los lectores ópticos de caracteres. Esto
implica que se pueden introducir marcas fuera de lugar en los formularios como datos incorrectos. Además, las
opciones se limitan a las respuestas proporcionadas en el formulario de detección de marcas, los formularios pre-
sentan dificultades al capturar datos alfanuméricos debido al espacio requerido para un conjunto completo de le-
tras y números, y es fácil que los usuarios que llenan formularios de detección de marcas se confundan y pongan
una marca en una posición incorrecta.
Códigos de barras Por lo general, los códigos de barras aparecen en las etiquetas de productos, pero también
aparecen en brazaletes de identificación de pacientes en los hospitales y casi en cualquier contexto en el que una
persona u objeto necesite reportarse como entrada o salida en cualquier tipo de sistema de inventario. Podemos
considerar a los códigos de barras como metacódigos, o códigos que codifican otros códigos, debido a que
aparecen como una serie de bandas estrechas y anchas en una etiqueta, las cuales codifican números o letras. A su
vez, estos símbolos tienen acceso a los datos de los productos almacenados en la memoria de la computadora.
Se proyecta un rayo de luz de un escáner o lápiz óptico a través de las bandas en la etiqueta para confirmar o
registrar datos sobre el producto que se está escaneando.
Una etiqueta de código de barras como la que se muestra en la figura 15.15 incluye los siguientes elementos
de codificación para un producto específico de abarrotes: el número de identificación del fabricante, el número de
identificación del producto, un código para verificar la precisión del escaneo y códigos para marcar el principio
y fin del escaneo.
Los códigos de barras ofrecen un grado de precisión extraordinariamente elevado para la entrada de datos.
Ahorra costos de mano de obra a los vendedores, ya que no hay que marcar el precio de cada artículo por sepa-
rado. Además, la codificación de barras permite capturar de manera automática datos que se pueden utilizar para
reordenar, rastrear el inventario con mayor precisión y pronosticar las necesidades a futuro. Los precios de venta
u otros cambios en el significado de los códigos de barras se introducen en el procesador central, con lo cual nos
ahorramos el problema de rebajar muchos artículos.
Un nuevo uso de los códigos de barras es el de rastrear las compras de un individuo con su tarjeta de crédito,
con el fin de crear un perfil de cliente que pueda a su vez utilizarse para refinar las estrategias de marketing para
ese individuo o tipo de consumidor. Se desarrollan nuevos dispositivos de entrada en forma constante.
RFID La identificación por radiofrecuencia, conocida comúnmente como RFID, permite recolectar datos en
forma automática mediante etiquetas RFID o transpondedores que contienen un chip y una antena. Una etiqueta
RFID puede o no tener su propia fuente de energía. Si no cuenta con su propia fuente, la antena provee suficiente
potencia de una señal entrante para energizar el chip y transmitir una respuesta. Las etiquetas RFID se pueden
adjuntar a productos, paquetes, animales o incluso humanos, de manera que se pueda identificar el elemento o
persona mediante una frecuencia de radio.
A las etiquetas RFID también se les conoce como tarjetas de proximidad debido a su rango limitado; pue-
den ser pasivas o activas. Las etiquetas RFID pasivas no tienen fuente de energía interna; las activas sí. Las eti-
quetas pasivas son económicas (menos de 5 centavos de dólar por etiqueta) y por lo general tienen el tamaño de
una estampilla postal. Se utilizan en las grandes tiendas de menudeo, incluyendo Wal-Mart y Target. Wal-Mart
ha estado trabajando mucho con la tecnología RFID para mejorar sus procesos de administración de inventario y
cadena de suministro.
Las etiquetas activas son mucho más confiables, ya que tienen su propia fuente de energía. El Departamento
de Defensa de los EE.UU. ha utilizado estas etiquetas para minimizar los costos relacionados con la logística e
incrementar la visibilidad de la cadena de suministro. Las etiquetas activas cuestan sólo unos cuantos dólares
cada una.
Principio (101)
Código que significa “producto de abarrotes”
Número de identificación del fabricante
(primeros cinco dígitos)
Barras de separación centrales (01010)
Número de identificación del producto
(últimos cinco dígitos)
Código para verificar la precisión del escaneo
(dígito de verificación)
Fin (101)
FIGURA 15.15
El código de barras, como se
muestra en esta etiqueta para un
producto de abarrotes, ofrece
mucha precisión en la entrada de
datos.
Utilizada con el permiso de Uniform
Code Council, Dayton, Ohio.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 499
Para capturar los datos en una etiqueta RFID se requiere un lector. Este lector activa la etiqueta para que se
pueda leer. El lector decodifica los datos y el código único de producto en el chip dentro de la etiqueta; después
lo pasa a una computadora anfitriona que procesa los datos.
Un ejemplo es el paso de peaje electrónico que se utiliza en los vehículos que viajan por las carreteras de
cuota. Se puede colocar un transpondedor RFID en el parabrisas para leerlo cada vez que el vehículo pasa por
una caseta de cuota. El lector RFID de la caseta de cuota también puede actuar como escritor, por lo que se
puede almacenar un saldo en el chip RFID.
El Metro de Moscú fue el primer sistema de transporte en usar tarjetas inteligentes RFID en 1998. Otras
aplicaciones incluyen el rastreo de ganado para identificar la manada de origen, lo cual permite rastrear mejor la
enfermedad de las vacas locas, así como el rastreo RFID en librerías, servicios de equipaje de aerolíneas, farma-
cias e incluso pacientes o internos.
Las etiquetas RFID son de uso común en la mayoría de las aplicaciones relacionadas con envíos. La tecnolo-
gía pronto se utilizará en las transacciones de efectivo electrónico en general. Incluso pueden llegar a reemplazar
los códigos RPC, ya que sus ventajas incluyen la seguridad (al reducir el número de artículos robados) y no re-
querir escaneo (simplemente se pasan por la zona del lector).
Pero la tecnología RFID no escapa de la controversia. La privacidad es una cuestión importante. Un indivi-
duo que paga un artículo etiquetado con tarjeta de crédito o con una tarjeta de comprador corre el riesgo de ser
identificado.
El analista de sistemas necesita pensar en los clientes involucrados y sus derechos al considerar si esta tec-
nología se adapta a la aplicación que está diseñando.
ASEGURAR LA CALIDAD DE LOS DATOS POR MEDIO DE LA VALIDACIÓN
DE LA ENTRADA
Hasta ahora hemos visto cómo asegurar la captura efectiva de datos hacia documentos de origen y la entrada
eficiente de datos al sistema por medio de diversos dispositivos de entrada. Aunque estas condiciones son nece-
sarias para asegurar datos de calidad, por sí solas no son suficientes.
Los errores no se pueden descartar por completo; además no podemos sobre enfatizar la importancia crítica
de atrapar errores durante la entrada, antes de procesarlos y almacenarlos. La maraña de problemas que surgen de-
bido a una entrada incorrecta puede ser una pesadilla, en especial porque una gran cantidad de problemas tardan
O P O R T U N I D A D D E C O N S U L T O R Í A 1 5 . 3
Entrar o no entrar: esa es la cuestión
“Acabo de asumir la presidencia de Elsinore Industries”, dice
Rose N. Krantz. “Formamos parte de una industria de fabricación
de casitas pequeñas, donde fabricamos aldeas de juguete para niños de
siete años en adelante. Nuestras pequeñas aldeas consisten de varios
kits para construir lo que quieran los niños a partir de cubos de plás-
tico que se conectan entre sí, que pueden ser edificios básicos como
la presidencia municipal, la estación de policía, la estación de gaso-
lina y un carrito para hot-dogs. Cada kit tiene un número de pieza
único de 200 a 800, pero no se utilizan todos los números. Los
precios de mayoreo varían de $54.95 por la presidencia municipal
a $1.79 para un carrito de hot-dogs.
“He estado melancólica en relación con lo que descubrí desde
que entré a trabajar en Elsinore. ‘Algo huele a podrido’ aquí, como
dice un famoso dramaturgo. De hecho, el sistema de facturación
estaba tan descontrolado que he estado trabajando sin cesar con
nuestra contadora, Gilda Stern”, declara Krantz.
“Me gustaría que nos ayudara a ordenar todo”, continúa Rose.
“Enviamos a 12 almacenes de distribución por todo el país. Cada
factura que escribimos incluye el número de almacén, del 1 al 12,
su dirección física y el código postal estadounidense (zip code).
También ponemos en cada factura la fecha en que surtiremos el
pedido, los números de código para los kits de la aldea que ordenen,
una descripción de cada kit, el precio por artículo y la cantidad de
cada kit ordenado. Desde luego que también incluimos los subtota-
les de los costos de los kits, los costos de envío y el total que el al-
macén nos debe. No se agregan impuestos, ya que lo que nosotros
les vendemos lo revenden a las jugueterías en los 50 estados. Quiero
que usted nos ayude a diseñar un sistema computarizado de intro-
ducción de pedidos que forme parte del sistema de facturación de
Elsinore Industries”.
Para su diseño de un sistema de entrada de datos para Elsinore,
tome en cuenta todos los objetivos para entrada de datos que vimos
en el capítulo. Dibuje las pantallas que sean necesarias para ilustrar
su diseño. ¿Cómo puede hacer que el sistema de introducción de
pedidos sea eficiente? Responda en un párrafo. Especifique los
datos que se pueden almacenar y recuperar, junto con los datos que
se deben introducir de nuevo para cada pedido. ¿Cómo se puede
evitar el trabajo innecesario? Escriba un párrafo para explicar por
qué el sistema que usted propone es más eficiente que el anterior.
¿Cómo se puede asegurar la precisión de los datos? Mencione tres
estrategias que funcionen con el tipo de datos que se van a introdu-
cir para Elsinore Industries.www.xlibros.com

500 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
mucho tiempo en hacerse ver. El analista de sistemas debe suponer que ocurrirán errores en los datos y debe
trabajar con los usuarios para diseñar pruebas de validación de la entrada, de manera que pueda evitar que se
procesen y almacenen datos erróneos, ya que los errores iniciales que no se descubren durante largos periodos
de tiempo son costosos y se requiere mucho tiempo para corregirlos.
No es posible imaginar todo lo que puede salir mal con la entrada, pero debemos cubrir los tipos de errores
que provocan el mayor porcentaje de los problemas. En la figura 15.16 se proporciona un resumen de los proble-
mas potenciales que debemos considerar al validar la entrada.
Validar las transacciones de entrada
El proceso de validar las transacciones de entrada se realiza principalmente por medio de software, lo cual es
responsabilidad del programador, pero es importante que el analista de sistemas conozca los problemas comunes
que pueden invalidar una transacción. Las empresas comprometidas con la calidad incluirán chequeos de validez
como parte de su software de rutina.
Pueden ocurrir tres problemas principales con las transacciones de entrada: que se envíen los datos incorrec-
tos al sistema, que una persona no autorizada envíe los datos o que se pida al sistema que realice una función
inaceptable.
ENVIAR LOS DATOS INCORRECTOS Un ejemplo de enviar datos incorrectos al sistema sería tratar de introducir
el número de seguro social de un paciente en el sistema de nóminas de un hospital. Por lo general este error es
accidental, pero hay que marcarlo antes de procesar los datos.
DATOS ENVIADOS POR UNA PERSONA NO AUTORIZADA El sistema también debe ser capaz de descubrir si
una persona no autorizada envía datos por lo demás correctos. Por ejemplo, sólo el farmacéutico supervisor
podría introducir los totales del inventario para las sustancias controladas en la farmacia. La invalidación de
las transacciones enviadas por un individuo no autorizado se aplica a las cuestiones de privacidad y seguridad
relacionadas con los sistemas de nómina y los registros de evaluación de empleados que determinan los niveles
de los pagos, las promociones o la disciplina; los archivos que contienen secretos comerciales; y los archivos que
contienen información clasificada, como los datos de defensa nacional.
PEDIR AL SISTEMA QUE REALICE UNA FUNCIÓN INACEPTABLE El tercer error que invalida las transacciones de
entrada es pedir al sistema que realice una función inaceptable. Por ejemplo, sería lógico que el gerente de recur-
sos humanos actualizara el registro existente de un empleado actual, pero sería inválido pedir al sistema que
creara un nuevo archivo en vez de sólo actualizar un registro existente.
Validar los datos de entrada
Es esencial que los datos de entrada (junto con las transacciones solicitadas) sean válidos. Se pueden incorporar
varias pruebas al software para asegurar esta validez. Vamos a considerar ocho posibles formas de validar la en-
trada.
PRUEBA DE DATOS FALTANTES En el primer tipo de prueba de validez se examinan los datos para ver si hay
elementos faltantes. En algunas situaciones deben estar presentes todos los datos. Por ejemplo, un archivo del
seguro social para pagar los beneficios por retiro o discapacidad sería inválido si no incluyera el número de
seguro social del beneficiario.
Este tipo de
validación Puede evitar estos problemas
Validar transacciones
de entrada
Validar datos de
entrada
Enviar los datos incorrectos
Datos enviados por una persona no autorizada
Pedir al sistema que realice una función
inaceptable
Datos faltantes
Longitud de campo incorrecta
Datos con una composición inaceptable
Datos fuera de rango
Datos inválidos
Datos que no coinciden con los datos
almacenados
FIGURA 15.16
Es importante validar la entrada
para asegurar que se eliminen lo
más pronto posible la mayoría de
los problemas potenciales con los
datos.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 501
Además, el registro debe incluir los datos clave que distinguen a un registro de todos los demás, junto con
el código de función que indica a la computadora lo que debe hacer con los datos. El analista de sistemas ne-
cesita interactuar con los usuarios para determinar qué elementos de datos son esenciales y averiguar si alguna
vez ocurrieron casos excepcionales que permitieran considerar los datos válidos, incluso cuando faltaran algunos
elementos de datos. Por ejemplo, una segunda línea de dirección que contenga un número de apartamento o la
inicial del segundo nombre de una persona tal vez no sea una entrada requerida.
PRUEBA DE LONGITUD DE CAMPO CORRECTA En el segundo tipo de prueba de validez se comprueba la entrada
para ver si tiene la longitud correcta para el campo. Por ejemplo, si la estación climatológica de Omaha,
Nebraska se reporta con la computadora del servicio climatológico nacional y por error provee un código de
ciudad de dos letras (OM) en vez del código nacional de ciudad de tres letras (OMA), los datos de entrada se
podrían considerar inválidos y por ende no se procesarían.
PRUEBA DE CLASE O COMPOSICIÓN La prueba de la validez de la clase o composición verifica que todos los
campos de datos que deben estar compuestos exclusivamente de números no contengan letras y viceversa. Al
usar una prueba de composición, el programa no debe aceptar un número de cuenta de American Express que
incluya tanto letras como números.
PRUEBA DE RANGO O SENSATEZ Las pruebas de validez de rango o sensatez son en realidad medidas de entrada
de sentido común, las cuales responden a la pregunta de si los datos se encuentran dentro de un rango aceptable
o si son razonables dentro de ciertos parámetros predeterminados. Por ejemplo, si un usuario estaba tratando
de verificar una fecha de envío propuesta, la prueba de rango no permitiría una fecha de envío en el día 32 de
octubre, ni aceptaría un envío en el mes 13, siendo los rangos respectivos de 1 a 31 días y de 1 a 12 meses.
Una prueba de sensatez averigua si el elemento tiene sentido para la transacción. Por ejemplo, al agregar
un nuevo empleado a la nómina, no sería razonable introducir una edad de 120 años. Las pruebas de sensatez se
utilizan para los datos que son continuos; es decir, datos que tienen un rango uniforme de valores. Estas pruebas
pueden incluir un límite inferior, un límite superior o ambos.
PRUEBA DE VALORES INVÁLIDOS El proceso de comprobar que la entrada no tenga valores inválidos funciona
si sólo hay unos cuantos valores válidos. Esta prueba no es viable para las situaciones en las que los valores
no son restringidos ni predecibles. Este tipo de prueba es útil para verificar las respuestas donde los datos se
dividen en un número limitado de clases. Por ejemplo, una empresa de correduría divide las cuentas en tres
clases solamente: clase 1 cuenta activa, clase 2 cuenta inactiva y clase 3 cuenta cerrada. Si los datos se
asignan a cualquier otra clase por medio de un error, los valores son inválidos. Por lo general las verificaciones
de valores se realizan para los datos discretos, que sólo tienen ciertos valores. Si hay muchos valores, por lo
general se almacenan en un archivo de tabla de códigos. Al tener los valores en un archivo es más fácil agregar
o modificar valores.
VERIFICACIONES DE REFERENCIAS CRUZADAS Estas verificaciones se utilizan cuando un elemento tiene una
relación con otro. Para realizar una verificación de referencia cruzada, cada campo debe estar correcto por sí
solo. Por ejemplo, el precio al que se vende un artículo debe ser mayor que el costo que se paga por él. Hay que
introducir el precio, el cual debe ser numérico y mayor de cero. Se utiliza el mismo criterio para validar el costo.
Cuando tanto el precio como el costo son válidos, se pueden comparar.
Una verificación geográfica es otro tipo de verificación de referencia cruzada. En los Estados Unidos se
puede utilizar la abreviatura de estado para asegurar que un código de área telefónica sea válido para cierto es-
tado y que los primeros dos dígitos del código postal sean válidos para el estado.
PRUEBA PARA COMPARAR CON DATOS ALMACENADOS La siguiente prueba de validez de los datos de entrada
que veremos es en la que éstos se comparan con los datos que ya están almacenados en la computadora. Por
ejemplo, un número de pieza recién introducido se puede comparar con el inventario de piezas completo para
asegurar que el número exista y se esté introduciendo en forma correcta.
CONFIGURAR CÓDIGOS DE AUTOVALIDACIÓN (DÍGITOS DE VERIFICACIÓN) Otro método para asegurar la
precisión de los datos, en especial los números de identificación, es utilizar un dígito de verificación en el mismo
código. Este procedimiento implica empezar con un código numérico original, realizar algunas operaciones
matemáticas para llegar a un dígito de verificación derivado y después agregar ese dígito de verificación al
código original. El proceso matemático implica multiplicar cada uno de los dígitos del código original por
ciertos pesos predeterminados, sumar estos resultados y después dividir esta suma por un número módulo. El
número módulo es necesario debido a que la suma por lo general es un número grande y necesitamos reducir
el resultado a un solo dígito. Por último, el residuo se resta del número módulo para obtener el dígito de
verificación.www.xlibros.com

502 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
La figura 15.17 muestra cómo se convierte el número de pieza de cinco dígitos de una manguera para radia-
dor (54823) en un número de seis dígitos que contiene un dígito de verificación. En este ejemplo, los pesos elegidos
fueron el sistema “1-3-1”; en otras palabras, los pesos alternan entre 1 y 3. Después de multiplicar los dígitos 5,
4, 8, 2 y 3 por 1, 3, 1, 3 y 1, se convirtieron en 5, 12, 8, 6 y 3. La suma de estos nuevos dígitos es 34. Después el
34 se divide entre el número módulo elegido, 10, para obtener el resultado de 3 y un residuo de 4. El residuo (4)
se resta del número módulo (10) para obtener un dígito de verificación de 6. Ahora el dígito 6 se coloca al final
del número original para producir el código del producto oficial para la manguera de radiador (548236).
Uso de los dígitos de verificación El sistema de dígitos de verificación funciona de la siguiente manera. Suponga
que tenemos el número de pieza 53411. Hay que teclear este número en el sistema, y mientras hacemos eso
pueden ocurrir distintos tipos de errores. Uno de los posibles errores es teclear mal un dígito; por ejemplo, el
empleado teclea 54411 en vez de 53411. Sólo el dígito en la posición de los miles es incorrecto, pero este error
puede provocar que se envíe la pieza incorrecta.
Un segundo tipo de error es el de los dígitos transpuestos. Es común que el número deseado 53411se teclee
como el número 54311, sólo debido a que dos teclas se oprimieron en orden inverso. Los errores de transposi-
ción también son difíciles de detectar para los humanos.
Podemos evitar estos errores mediante el uso de un dígito de verificación, ya que cada uno de estos nú-
meros (el correcto y el erróneo) tendrían un número de dígito de verificación distinto, como se muestra en la
Elegir el método de ponderación
y el número módulo a usar en
todos los cálculos.
Multiplicar el dígito por el peso
elegido.
Sumar los nuevos números
Dividir entre el número
módulo.
Calcular el dígito de verificación:
tomar el número módulo y
restar al residuo (restar de
nuevo si es mayor de 10).
Agregar dígito de verificación al
final del número.
Usar este nuevo código para la
entrada de datos y dejar que
la computadora valide el código.
54823
“1 × 3 × 1” y 10
5
× 1
5
34
10
4
× 3
12
8
× 1
8
2
× 3
6
3
× 1
3
5 + 12 + 8 + 6 + 3 = 34
= 3 con un residuo de 4
10 – 4 = 6
54823 6
548236
Empezar con el código numérico.
FIGURA 15.17
Los pasos para convertir un
número de pieza de cinco dígitos
en un número de seis dígitos que
contiene un dígito de verificación.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 503
figura 15.18. Si el número de pieza 53411 se modificara a 534118 (incluyendo el dígito de verificación 8) y
ocurriera cualquiera de los dos errores antes descritos, se atraparía el error. Si el segundo dígito se tecleara
en forma equivocada como 4, la computadora no aceptaría 544118 como un número válido, ya que el dígito
de verificación para 54411 sería 5 y no 8. De manera similar, si se transpusieran el segundo y tercer dígitos,
como en 543118, la computadora también rechazaría el número debido a que el dígito de verificación para
54311 sería 6 y no 8.
El analista de sistemas selecciona los pesos y el número módulo, pero una vez elegidos no deben cambiar.
En la figura 15.19 encontrará algunos ejemplos de métodos de ponderación y números módulo.
VERIFICACIÓN DE TARJETAS DE CRÉDITO Al introducir tarjetas de crédito en un sitio Web o programa de
computadora, la primera verificación es la longitud del número. Las compañías de tarjetas de crédito diseñaron
sus tarjetas para incluir un número distinto de dígitos. Por ejemplo, las tarjetas Visa son de 16 dígitos mientras
que los de las tarjetas American Express están compuestas por 15 dígitos.
Otra prueba es relacionar la compañía de la tarjeta de crédito y el banco para verificar que sea realmente una
tarjeta emitida por esa compañía. Por lo general los primeros cuatro dígitos indican el tipo de tarjeta. Los dígitos
de en medio comúnmente representan al banco y al cliente. El último dígito es de verificación.
Además de estos métodos de verificación, en el procesamiento de tarjetas de crédito se utiliza una fórmula
de dígitos de verificación conocida como fórmula Luhn, la cual se creó en la década de 1960. Suponga que tene-
Estado
Correcto
Código original
Dígito de
verificación Nuevo código
5 3 4 1 1
5 4 4 1 1
5 4 3 1 1
8 534118
Error al teclear un dígito 5 544115
Transposición 6 543116
FIGURA 15.18
Evitar errores de entrada de datos
comunes por medio del uso de un
dígito de verificación.
Método de dígito
de verificación Cálculos para agregar el dígito de verificación al número original 29645
Módulo 10
“2-1-2”
Módulo 10
“3-1-3”
Módulo 11
“Aritmético”
Módulo 10
“Geométrico”
= 39/10 = 3 residuo
2
× 2
4 +
9
× 1
9 +
6
× 2
12 +
4
× 1
4 +
10
(9)
1
10
(2)
8
5
× 2
10
2
× 3
6 +
9
× 1
9 +
6
× 3
18 +
4
× 1
4 +
5
× 3
15
2
× 6
12 +
9
× 5
45 +
6
× 4
24 +
4
× 3
12 +
5
× 2
10
2
× 32
64 +
9
× 16
144 +
6
× 8
48 +
4
× 4
16 +
5
× 2
10
Dígito de verificación igual a
El código con dígito de
verificación es 296451.
= 52/10 = 5 residuo
Dígito de verificación igual a
El código con dígito de
verificación es 296458.
11
(4)
7
= 103/11 = 9 residuo
Dígito de verificación igual a
El código con dígito de
verificación es 296457.
11
(7)
4
= 282/11 = 25 residuo
Dígito de verificación igual a
El código con dígito de
verificación es 296454.
FIGURA 15.19
Ejemplos de métodos de
ponderación y números módulo.www.xlibros.com

504 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
mos un número 7-7-7-8-8-8, donde los primeros cinco números representan un número de cuenta bancaria y el
último dígito es de verificación. Vamos a aplicar la fórmula de Luhn para ver si es un número válido.
1. Duplique el penúltimo dígito y después los demás dígitos (es decir, omita un dígito, duplique el siguiente,
omita un dígito, duplique el siguiente, etc.). Por ejemplo, el número 7-7-7-8-8-8 se convierte en 14-7-14-8-
16-8.
2. Si al duplicar un dígito se produce un número mayor de 10, hay que reducir este número de dos dígitos a un
solo dígito, para lo cual se suman los dos números. En nuestro ejemplo, el 14 se convierte en 1 4 5 y el
16 se convierte en 1 6 7. Después de esto, nuestro número original 7-7-7-8-8-8 se ha transformado en
un nuevo número, 5-7-5-8-7-8.
3. Ahora sume todos los dígitos en el nuevo número. Así, 5 7 5 8 7 8 40.
4. Vea el total. Si termina en cero, el número es válido de acuerdo con la fórmula de Luhn. Como 40 termina
en cero, podemos decir que pasa la prueba de la fórmula de Luhn.
Podemos usar la fórmula de Luhn para identificar los errores al introducir una tarjeta de crédito incorrecta. Por
ejemplo, el número de tarjeta de crédito 1334-1334-1334-1334 es válido, debido a que los dígitos del número
transformado 2364-2364-2364-2364 se suman para un total de 60, un número que termina en cero. Si un usuario
introduce un dígito incorrecto, el total no será un múltiplo de cero.
Sin embargo, la fórmula de Luhn no atrapa todos los errores. Si un usuario comete errores al introducir más
de un dígito —por ejemplo, si introduce 1334-1334-1334-331— el total del número transformado (2364-2364-
2364-6324) sigue siendo 60. Este error de transposición (invertir el tercer y cuarto dígitos de derecha a izquierda)
no se atrapará.
Las compañías de tarjetas de crédito también usan la fecha de expiración y un código de verificación de tres
o cuatro dígitos, a menudo escrito en el lado posterior de la tarjeta para una mayor seguridad.
Las siete pruebas para verificar la validez de la entrada pueden ayudar de manera considerable a proteger
el sistema contra la entrada y el almacenamiento de datos erróneos. Siempre debemos suponer que es mucho
más probable que ocurran errores humanos en la entrada a que no ocurran. Es su responsabilidad como analista
comprender cuáles errores invalidarán los datos y cómo usar la computadora para protegerse contra esos errores
humanos, para así limitar su intrusión en los datos del sistema.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 5 . 4
¿Validan el estacionamiento?
“ Qué vamos a hacer, Mercedes?”, pregunta Edsel con cansan-
cio. Mercedes y Edsel están revisando la impresión de facturación
más reciente para su empresa, Denton and Denton Parking Garages.
Han estado comprando servicios de facturación por lotes de una
empresa local pequeña de servicios de computadora desde que ad-
quirieron tres estacionamientos cerrados en un área metropolitana
de tamaño medio. La empresa Denton and Denton Parking Garages
renta lugares de estacionamiento por día, mes y año a las empresas
e individuos.
Mercedes responde: “No estoy segura de cuál será nuestro si-
guiente movimiento, pero la facturación está toda mal. Tal vez de-
beríamos tratar de hablar con el personal de TI”.
“Dijeron que podrían averiguar cómo calcular estos costos
viendo lo que habían hecho a mano los dueños anteriores, y dijeron
que no querían ejecutar el sistema antiguo y el nuevo en paralelo”,
comenta Edsel al tiempo que sacude la cabeza. “Pero eso no está
bien. Por lo menos yo no puedo resolverlo. Tal vez usted pueda”.
Mercedes acepta la noción de buscar la salida sospechosa y
empieza a analizar el informe con detalle. “Bueno, al fin y al cabo no
saben que recibimos automóviles de todas partes. Cada vez que reci-
bimos un automóvil con placas que no son del estado, parece como si
la computadora dejara de imaginar. Mira, nuestras placas empiezan con
un número y después una letra, ¿verdad? Bueno, este de Nueva York
empieza con tres letras. La computadora no puede manejarlo”, dice.
Edsel se integra a la conversación y empieza a pensar sobre la
empresa mientras analiza el documento impreso. “Sí, y mira aquí.
Esta persona no tiene un número de cuenta anual, sólo mensual, por
lo que no salió ninguna factura”, dice. “Tenemos clientes mensuales
también, y la computadora no lo sabe”.
“Y mira esto. Todavía hace cobros diarios por los tres días de
noviembre que les dijimos que no había vacantes para los clientes
diarios. No es razonable”, afirma Mercedes.
Edsel continúa avanzando página por página en el documento
impreso, pero Mercedes lo detiene y dice: “Ya no sigas viendo. Voy
a llamar al personal de TI para poder arreglar este desorden”.
¿Cómo caracterizaría los problemas que se encontraron en el
sistema de facturación actual del estacionamiento? Use un párrafo
para formular una respuesta. ¿Cuáles son algunas de las pruebas de
validez de datos que se podrían incluir en el software para producir
un sistema de facturación revisado para los estacionamientos? Haga
una lista. ¿Qué podrían haber hecho distinto el programador y los
analistas de la empresa de servicios de cómputo para que el cliente no
tuviera qué corregir la salida de mala calidad? Use tres párrafos para
realizar un análisis crítico de lo que se hizo y lo que se debió hacer.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 505
El proceso de validación
Es importante validar cada campo hasta que sea válido o se detecte un error. El orden de prueba de los datos es
primero verificar si hay datos faltantes. Después, una prueba de sintaxis puede verificar la longitud de los datos
introducidos y que éstos tengan una clase y composición apropiadas. Sólo después de que la sintaxis sea correcta
se validará la semántica o significado de los datos. Esto incluye una prueba de rango, razonable o de valor, se-
guida de una prueba de dígito de verificación.
Las pantallas de GUI ayudan a reducir el número de errores de entrada humanos cuando incorporan boto-
nes de opción, casillas de verificación y listas desplegables. Cuando se utilizan botones de opción, uno se debe
establecer como el predeterminado y la única forma de deseleccionarlo es si el usuario hace clic en un botón de
opción distinto. En caso de las listas desplegables, la primera elección siempre debe contener un mensaje para
informar al usuario que debe cambiar la lista. Si la primera opción sigue aún seleccionada al momento de enviar
el formulario, un mensaje debería informarle que debe seleccionar una opción distinta.
Por lo general, la validación de un solo campo se realiza mediante una serie de instrucciones IF...ELSE,
pero también hay métodos de validación de patrones. Por lo general estos patrones se encuentran en el diseño
de la base de datos (como en Microsoft Access), pero también se pueden incluir en lenguajes de programación
como Perl, JavaScript y esquemas de XML. A los patrones se les conoce como expresiones regulares y contienen
símbolos que representan el tipo de datos que deben estar presentes en un campo. La figura 15.20 muestra los
caracteres que se utilizan en las expresiones regulares de JavaScript.
A continuación le mostramos un ejemplo de validación de patrón utilizado para evaluar una dirección de
correo electrónico:
[A-Za-z0-9]\w{2,}@[A-Za-z0-9]{3,}\.[A-Za-z]{3}/
El significado de este patrón es el siguiente: la primera letra debe ser cualquier letra mayúscula, minúscula o
número ([A-Za-z0-9]). Esto va seguido de dos o más caracteres que son cualquier letra, número o un guión bajo
(\w{2,}). Después debe haber un símbolo @, seguido de por lo menos tres letras o números, un punto y exacta-
mente tres caracteres después del punto.
Una verificación de referencias cruzadas supone que la validez de un campo puede depender del valor de
otro campo. Un ejemplo de una verificación de referencia cruzada es verificar una fecha válida. En un caso muy
especial, la validez del día del mes depende del año. Es decir, febrero 29 es sólo válido durante los años bisies-
tos. Una vez que se han verificado los campos individuales, podemos realizar verificaciones de referencias cruza-
das. Obviamente, si uno de los campos es incorrecto, la verificación de referencia cruzada no tiene sentido y no
se debe llevar a cabo.
Código de
carácter
Significado utilizado en la validación
con expresiones regulares
\d
\D
\w
\W
.
[caracteres]
[car-car]
[a–z][A–Z][0–9]
[^caracteres]
[^car-car]
[^a–z]
{n}
{n,}
\s
\S
Cualquier dígito del 0-9
Cualquier carácter que no sea dígito
Cualquier letra, número o guión bajo
Cualquier carácter distinto de una letra, número o guión
bajo
Coincide con cualquier carácter
Coincide con los caracteres dentro de los corchetes
Coincide con el rango de caracteres
Acepta cualquier letra o dígito
Coincide con cualquier cosa que no sean los caracteres
Coincide con cualquier cosa fuera del rango de caracteres
Aceptará todo excepto letras minúsculas
Coincide con exactamente n ocurrencias del carácter
anterior
Coincide con al menos n ocurrencias del carácter
Cualquier carácter de formato de espacio en blanco
(tabulador, nueva línea, retorno, etc.)
Cualquier carácter que no sea de espacio en blanco
FIGURA 15.20
Estos caracteres se utilizan en la
validación con expresiones
regulares (patrones).www.xlibros.com

506 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Para validar documentos XML debemos compararlos con una definición de tipo de documento (DTD) o
con un esquema (consulte el capítulo 8). La DTD verificará si el formato del documento es válido, pero un es-
quema es mucho más potente y verificará el tipo de datos (por ejemplo, entero corto o largo, número decimal o
fecha). Un esquema también verificará un rango de valores, el número de dígitos a la izquierda y a la derecha de
un punto decimal, y los valores de los códigos. Hay herramientas gratuitas para validar una DTD o un esquema.
IEXMLTLS es una extensión de Microsoft para Internet Explorer, la cual agrega nuevas opciones de menú
cuando el usuario hace clic con el botón derecho en un documento de XML.
VENTAJAS DE LA PRECISIÓN EN LOS ENTORNOS DE COMERCIO
ELECTRÓNICO
Uno de los muchos beneficios de las transacciones de comercio electrónico es una mayor precisión de los datos,
debido a cuatro razones:
1. Por lo general los clientes teclean o introducen los datos ellos mismos.
2. Los datos que introducen los clientes se almacenan para su uso posterior.
3. Los datos que se introducen en el punto de ventas se reutilizan en todo el proceso de cumplimiento del pedido.
4. La información se utiliza como retroalimentación para los clientes.
Un analista debe estar consciente de las ventajas que se producen debido al comercio electrónico, la captura elec-
trónica y el uso de la información.
Los clientes teclean sus propios datos
En primer lugar, los clientes conocen su información mejor que cualquier otra persona. Saben cómo deletrear su
dirección física, saben si viven en una “Avenida” o “Calle” y conocen su propio código de área. Si transmiten
esta información por teléfono, es más fácil cometer un error al deletrear la dirección; si se introduce mediante
un formulario de papel vía fax, puede haber errores si la transmisión de fax es difícil de leer. Pero si los usuarios
introducen su propia información, aumenta la precisión.
Almacenar datos para su uso posterior
Una vez que los clientes introducen la información, ésta se puede almacenar en sus propias computadoras
personales. Si regresan a ese sitio de comercio electrónico y llenan el mismo formulario para completar una
segunda transacción, experimentarán la ventaja de almacenar esta información. Cuando empiecen a teclear su
nombre, una lista desplegable les mostrará su nombre completo incluso cuando sólo hayan introducido un par
de caracteres. Si hacen clic en este indicador se introducirá su nombre completo y no tendrán que teclear más en
ese campo. Esta característica de autocompletar puede sugerir coincidencias para la información de tarjetas de
crédito y contraseñas también; además, esta información se cifra para que los sitios Web no puedan leer la infor-
mación almacenada en la computadora del usuario.
Las empresas que desean almacenar información para permitir transacciones cada vez más rápidas lo hacen
en pequeños archivos conocidos como cookies. Sólo la empresa que colocó la cookie en la computadora del
usuario podrá acceder a la información personal.
Utilizar datos por medio del proceso de cumplimiento de pedidos
Cuando las empresas capturan información sobre el pedido de un cliente, pueden usar y reutilizar esa información
en todo el proceso de cumplimiento del pedido. Así, la información recopilada para completar un pedido también
se puede usar para enviar una factura a un cliente, obtener el producto del almacén, enviar el producto, enviar
retroalimentación al cliente y reabastecer el producto enviando una notificación al fabricante. También se puede
volver a utilizar para enviar un catálogo impreso al cliente, o enviarle una oferta especial por correo electrónico.
Estas mejoras del comercio electrónico reemplazan a la metodología tradicional en la que se utilizaba un pro-
ceso de obtención basado en papel, donde las órdenes de compra se enviaban vía correo convencional o fax. Este
proceso electrónico no sólo agiliza la entrega del producto sino que también incrementa la precisión para que el
producto se entregue en la dirección correcta. En vez de leer un fax o un formulario enviado por correo conven-
cional, un despachador utiliza la versión electrónica de los datos, que es más precisa. La información electrónica
permite administrar mejor la cadena de suministro, incluyendo la verificación del producto y la disponibilidad de
recursos en forma electrónica, además de automatizar los procesos de planificación, calendarización y proyección.
Proveer retroalimentación a los clientes
Las confirmaciones y actualizaciones del estado del pedido son formas de mejorar la retroalimentación para los
clientes. Si un cliente recibe la confirmación de un error en un pedido que acaba de hacer, se puede corregir dewww.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 507
Es imprescindible asegurar la calidad de la entrada de datos en
el sistema de información para poder asegurar una salida de
calidad. Podemos mejorar la calidad de los datos introducidos
a través de una codificación efectiva, un proceso efectivo y efi-
ciente de captura de datos y la validación de los datos.
Podemos agilizar la manera en que los humanos introdu-
cen los datos mediante el uso efectivo de la codificación, que se
encarga de colocar los datos en secuencias cortas de dígitos y/o
letras. Es posible usar códigos de secuencia simple y códigos
de derivación alfabética para seguir el progreso de un elemento
dado. Los códigos de clasificación y los códigos de secuencia
en bloque son útiles para diferenciar unas clases de elemen-
tos de otras. Los códigos de cifrado también son útiles debido
a que ocultan información sensible o restringida para los em-
pleados.
Los códigos también son convenientes para revelar infor-
mación a los usuarios, ya que pueden permitir a los empleados
localizar artículos en existencia y hacer la entrada de datos más
significativa. Los códigos de subconjuntos de dígitos signifi-
cativos usan subgrupos de dígitos para describir un producto.
Los códigos mnemónicos también revelan información al ser-
vir como ayudas para la memoria humana, de manera que un
operador pueda introducir los datos correctamente, o también
pueden ayudar al usuario. El conjunto de caracteres Unicode
incluye todos los símbolos de los lenguajes estándar. Podemos
mostrar páginas Web escritas en otros alfabetos si descargamos
un editor de método de entrada de Microsoft. Los códigos de
función son abreviaturas útiles para informar a las computado-
ras o las personas sobre las funciones a realizar o las acciones
a tomar.
Para la entrada de datos efectiva también debemos consi-
derar los dispositivos de entrada. Un formulario efectivo y bien
diseñado que sirva como documento de origen es el primer
paso. Los datos se pueden introducir mediante muchos méto-
dos, cada uno de los cuales tiene distintas velocidades y grados
de confiabilidad. Los teclados se rediseñaron para mejorar la
eficiencia y la ergonomía. El reconocimiento óptico de caracte-
res (OCR), el reconocimiento de caracteres de tinta magnética
(MICR) y los formularios de detección de marcas tienen cada
uno capacidades especiales para mejorar la eficiencia. Los có-
digos de barras también agilizan la entrada de datos, mejoran
la precisión de los datos y aumentan la confiabilidad. RFID
permite la recolección automática de datos mediante el uso de
etiquetas RFID en productos, personas o animales. Pueden me-
jorar los procesos de administración de inventario y la cadena
de suministro.
La precisión en la entrada de datos también se puede mejo-
rar mediante el uso de la validación de la entrada. Los analistas
deben trabajar con los usuarios para diseñar pruebas de valida-
ción de la entrada, de manera que se evite el procesamiento y
almacenamiento de datos erróneos, lo cual es costoso y poten-
cialmente perjudicial.
EXPERIENCIA DE HYPERCASE® 15
“Algunas veces creo que soy la persona más afortunada de la
tierra. Incluso cuando he estado aquí por cinco años, alejado del
Reino Unido todo ese tiempo, todavía disfruto el hecho de conocer
personas y hacer lo que hago. Sí, ya sé que Snowden es exigente.
Usted también lo ha experimentado, ¿verdad? Él, por su parte, ama
los códigos. A mí me parecen una molestia. Siempre los olvido o
trato de crear algunos, o algo por el estilo. Sin embargo, algunos de
los médicos piensan que son grandiosos. Deben ser todas esas abre-
viaturas en latín que estudiaron en la escuela de medicina. Escuché
que la asignatura más estresante que tiene usted esta semana tiene
algo que ver con introducir la información en el sistema de informes
de los proyectos. El grupo de capacitación quiere sus ideas, y las
quiere rápido. Le deseo buena suerte con eso. Oh, y cuando Snow-
den regrese de Tailandia, estoy seguro de que querrá echar un vis-
tazo a lo que su equipo ha estado haciendo”.
Preguntas de HyperCase
1. Use una herramienta CASE, un paquete de software como
Microsoft Access o un formulario de diseño impreso para
diseñar un procedimiento de entrada de datos para el sistema
de informes de proyectos propuesto para el grupo de
capacitación. Suponga que estamos especialmente
interesados en el personal de médicos de consulta, quienes no
desean pasar mucho tiempo tecleando grandes cantidades de
datos al usar el sistema.
2. Pruebe su procedimiento de entrada de datos con tres
compañeros de su equipo. Pida retroalimentación para saber
si el procedimiento es apropiado, dado el tipo de usuarios
que tendrá el sistema.
3. Rediseñe el procedimiento de entrada de datos para incluir la
retroalimentación que haya recibido. Explique en un párrafo
cómo sus cambios reflejarán los comentarios que recibió.
inmediato. Por ejemplo, suponga que un cliente envía sin querer un pedido de dos ejemplares de un DVD en vez
de una. Después de enviar el pedido, el cliente recibe un correo electrónico en el que se confirma el pedido. El
cliente detecta el error, se pone en contacto de inmediato con la empresa y corrige el pedido, con lo cual se evita
el tener que devolver la copia adicional del DVD. La precisión se mejora gracias a una mejor retroalimentación.
RESUMENwww.xlibros.com

508 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Hay que verificar las transacciones de entrada para ase-
gurar que la petición sea aceptable, esté autorizada y sea
correcta. Los datos de entrada se pueden validar mediante
software que utilice varios tipos de pruebas que verifiquen si
hay datos faltantes, la longitud de los elementos de datos, el
rango y la sensatez de los datos, y que no haya valores inváli-
dos. Los datos de entrada también se pueden comparar con los
datos almacenados para fines de validación. Una vez que se
introducen datos numéricos, se pueden verificar y corregir en
forma automática por medio de los dígitos de verificación y la
fórmula de Luhn.
Hay un orden establecido en la prueba de los datos para
validar cada campo. También hay métodos de validación me-
diante patrones que se encuentran en el diseño de la base de
datos o se incluyen en los lenguajes de programación. A los
patrones se les conoce como expresiones regulares y contienen
símbolos que representan el tipo de datos que debe haber en un
campo.
Los entornos de comercio electrónico nos ofrecen la opor-
tunidad de mejorar la precisión de los datos. Con un énfasis
apropiado en los elementos de diseño centrados en el usuario, los
clientes pueden introducir sus propios datos, almacenarlos para
su uso posterior, usar los mismos datos almacenados en todo el
proceso de cumplimiento del pedido y recibir retroalimentación
en relación con las confirmaciones y actualizaciones de los pe-
didos.
PALABRAS CLAVE Y FRASES
administración de la cadena de suministro
característica de autocompletar
codificación
código de autovalidación
código de barras
código de cifrado
código de clasificación
código de derivación alfabética
código de función
código de secuencia en bloque
código de secuencia simple
código de subconjunto de dígitos significativos
código nemónico
cookies
cuello de botella
diferenciados
dígito de verificación
expresión regular
fórmula de Luhn
formulario de detección de marcas
identificación por radiofrecuencia (RFID)
modificable
prueba de clase o composición
prueba de comparación con datos almacenados
prueba de datos faltantes
prueba de longitud de campo correcta
prueba de rango o sensatez
prueba de referencia cruzada
prueba de valores inválidos
reconocimiento de caracteres de tinta magnética (MICR)
reconocimiento óptico de caracteres (OCR)
redundancia en los datos de entrada
teclear
Unicode
validar la entrada
PREGUNTAS DE REPASO
1. ¿Cuáles son los cuatro principales objetivos de la entrada de datos?
2. Mencione los cinco propósitos generales de codificar los datos.
3. Defina el término código de secuencia simple.
4. ¿Cuándo puede ser útil un código de derivación alfabética?
5. Explique lo que se logra con un código de clasificación.
6. Defina el término código de secuencia en bloque.
7. ¿Cuál es el tipo más simple de código para ocultar información?
8. ¿Cuáles son los beneficios de usar un código de subconjunto de dígitos significativos?
9. ¿Cuál es el propósito de usar un código mnemónico para los datos?
10. Defina el término código de función.
11. Mencione los ocho lineamientos generales para una codificación apropiada.
12. ¿Qué son los datos modificables?
13. ¿Qué son los datos de diferenciación?
14. ¿Cuál es una manera específica de reducir la redundancia de los datos que se van a introducir?
15. Defina el término cuello de botella según su aplicación en la entrada de datos.
16. ¿Cuáles son las tres funciones repetitivas de la entrada de datos que una computadora puede realizar con más eficiencia
que un operador de entrada de datos?
17. Mencione seis métodos de entrada de datos.
18. Mencione los tres principales problemas que pueden ocurrir con las transacciones de entrada.
19. Defina RFID. ¿Cuáles son las diferencias entre las etiquetas RFID activas y pasivas?
20. Mencione dos ejemplos del uso de etiquetas RFID en la administración de procesos o de inventario en entornos de
ventas al menudeo o centros al cuidado de la salud.
21. ¿Cuáles son las ocho pruebas para validar los datos de entrada?
22. ¿Qué prueba verifica si los campos de datos se llenaron correctamente con números o letras?www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 509
23. ¿Qué error común no es detectado por la fórmula de Luhn?
24. ¿Qué prueba no permite que un usuario introduzca una fecha tal como octubre 32?
25. ¿Qué prueba asegura la precisión en los datos mediante la incorporación de un número en el mismo código?
26. Mencione cuatro mejoras en la precisión de los datos que pueden ofrecer las transacciones que se realizan a través de
sitios Web de comercio electrónico.
27. ¿Qué es Unicode y cómo se utiliza?
28. ¿Cuál es el proceso para validar los datos que se introducen en los campos?
29. ¿Qué es una expresión regular?
PROBLEMAS
1. Una pequeña universidad privada especializada en programas de graduados necesita llevar el registro de la lista de
estudiantes que a) hacen solicitud, b) son aceptados y c) se inscriben en la universidad. Por cuestiones de seguridad, la
universidad también debe enviar un informe al gobierno con una lista de los estudiantes extranjeros que se inscriben pero
no se registran. Sugiera un tipo de código para este fin y proporcione un ejemplo de su uso en la universidad, en donde
se demuestre si es apropiado o no. ¿Cuáles son sus ventajas?
2. Las Ardillas de la Universidad Central Pacific han estado usando un código de secuencia simple para llevar el registro de
los que poseen abonos de temporada y los fanáticos que no poseen abonos de temporada de todos sus programas
deportivos. Se han producido varias confusiones desagradables.
Sugiera en un párrafo un esquema de codificación distinto que ayude a identificar en forma única a cada abonado y
explique cómo podrá este esquema evitar las confusiones.
3. El código utilizado por una tienda de helados para ordenar sus productos es 12DRM215-220. Este código se descifra de
la siguiente manera: 12 representa la cuenta de artículos en la caja, DRM representa a unas paletas de hielo llamadas
“Dreamcicles” (un tipo específico de novedad en el ámbito de los helados) y 215-220 indica toda la clase completa de
productos bajos en grasa con los que cuenta el distribuidor.
a. ¿Qué tipo de código se utiliza? Describa el propósito detrás de cada parte (12, DRM, 215-220) del código.
b. Construya una entrada codificada usando el mismo formato y la misma lógica para una novedad en los helados
conocida como Pigeon Bars, que vienen en un paquete de seis y no son bajos en grasa.
c. Construya una entrada codificada usando el mismo formato y la misma lógica para una novedad en los helados
conocida como Airwhips, que viene en un paquete de 24 y es un producto bajo en grasa.
4. Los operadores de entrada de datos en la empresa Michael Mulheren Construction han estado cometiendo errores al
introducir los códigos para los productos de recubrimientos residenciales, que son los siguientes: U estUco, A
Aluminio, R ladRillo, M Masonite, EZ masonite esmaltado tipo EZ color-lok, N recubrimiento de madera
Natural, PI acabado con PIntura, SH SHake SHingles. Sólo se permite un código por dirección.
a. Haga una lista de los posibles problemas con el sistema de codificación que podrían estar provocando entradas con
error. (Sugerencia: ¿Son las clases mutuamente excluyentes?).
b. Desarrolle un código mnemónico que ayude a los operadores a comprender lo que están introduciendo para mejorar
su precisión.
c. ¿Cómo rediseñaría las clases para los materiales de recubrimiento? Responda en un párrafo.
5. A continuación le mostramos un código para un producto en una extensa línea de cosméticos: L02002Z621289. La L
significa que es un lápiz labial, 0 significa que se introdujo sin barniz de uñas complementario, 2002 es un código de
secuencia que indica el orden en el que se produjo, Z es un código de clasificación que indica que el producto es
hipoalergénico y 621289 es el número de la planta (hay 15 plantas) donde se produce el producto.
a. Critique el código mediante una lista de las características que podrían provocar una entrada de datos imprecisa.
b. El diseñador Brian d’Arcy James es propietario de la empresa de cosméticos que utiliza este esquema de
codificación. Con un interés continuo en el nuevo diseño, Brian está dispuesto a considerar un código más elegante
que codifique la misma información de una mejor manera. Rediseñe el esquema de codificación y proporcione una
clave para su trabajo.
c. Escriba un enunciado para cada cambio que haya sugerido, indicando cuál problema de entrada de datos (del
problema 5a) eliminará ese cambio.
d. El Sr. d’Arcy James está encantado con su trabajo. Dice que a la empresa le gustaría contratarlo para que les ayudara
a expandir su actividad comercial para vender maquillaje para teatro (las obras como Wicked y Shrek con ocho
funciones por semana usan mucho maquillaje color verde). Agregue los nuevos códigos que sean necesarios para el
esquema de codificación que sugirió en el inciso b y proporcione una clave para su trabajo.
6. La empresa de cosméticos de d’Arcy James requiere que sus vendedores usen computadoras notebook para introducir
los pedidos de las tiendas departamentales (sus mayores clientes). Después esta información se transmite a los
almacenes y los pedidos se envían según el orden en el que hayan llegado. Por desgracia las tiendas están conscientes de
esta política y son muy competitivas en cuanto a cuál de ellas ofrecerá primero un nuevo producto de d’Arcy James.
Muchos vendedores han tomado el camino oscuro y han persuadido a los vendedores para que falsifiquen las fechas de
sus pedidos en los formularios de ventas, de manera que parezcan haberse hecho antes.
a. Este problema está creando una gran confusión en el almacén. No es viable disciplinar al personal involucrado.
¿Cómo se puede usar la computadora del almacén para certificar la fecha en que se realizan los pedidos? Explique
en un párrafo.www.xlibros.com

510 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
b. Los vendedores se quejan de que tienen que ignorar su verdadero trabajo de vender para poder teclear los datos.
Mencione los elementos de datos relacionados con las ventas de cosméticos a las tiendas que se deban almacenar y
recuperar de la computadora central, en vez de tener que teclearlos en cada pedido.
c. Describa en uno o dos párrafos cómo los códigos de barras podrían ayudar a resolver el problema del inciso 6b.
7. Mencione el mejor método de entrada de datos y la razón por la que lo eligió para cada una de las siguientes seis
situaciones:
a. El documento de respuesta para una empresa de servicios públicos que desea la notificación de un cambio en la
dirección del cliente.
b. Sólo se pueden recuperar datos si hay una identificación de máquina positiva de la parte que solicita los datos.
c. No hay suficiente personal capacitado disponible para interpretar respuestas largas por escrito; se enviaron muchos
formularios que capturan respuestas a exámenes de opción múltiple; es necesario un alto nivel de confiabilidad; no
se requiere un tiempo de respuesta rápido.
d. Se estableció un almacén para una operación de venta de discos compactos con descuento; los botes están
identificados con la información sobre el precio, pero los discos individuales no; hay pocos operadores
experimentados disponibles para introducir los datos de los precios.
e. Centro de control de venenos que mantiene una base de datos extensa de venenos y antídotos; necesita una manera
de introducir datos sobre el veneno ingerido; también hay que introducir el peso, edad y condición física general de
la víctima cuando una persona llama al número de atención gratuito del centro para obtener consejos de emergencia.
f. Un consumidor compró en línea un DVD con su tarjeta de crédito.
8. Ben Coleman, uno de los miembros de su equipo de análisis de sistemas, lo sorprende al afirmar que cuando un sistema
utiliza una prueba para la longitud de campo correcta, es redundante incluir también una prueba de rango o sensatez.
Describa en un párrafo un ejemplo que demuestre que Ben está equivocado en este caso.
9. Varios vendedores se reunieron y empezaron a emitir una tarjeta de crédito “estatal” que sólo es válida en las tiendas en
su estado. Como cortesía, se permite a los vendedores transcribir el número de cuenta de 15 dígitos a mano (después de
obtenerlo de la oficina de contabilidad) si el cliente no lleva consigo la tarjeta. El único problema con las cuentas que los
vendedores han detectado hasta ahora es que algunas veces se aceptan números de cuenta erróneos en el sistema de
cómputo, lo cual provoca que se envíe una factura a una cuenta inexistente.
a. ¿Qué tipo de prueba de validez resolvería el problema? ¿Cómo? Responda en un párrafo.
b. Sugiera un método de entrada de datos alternativo que podría solucionar este problema por completo.
10. Los siguientes son números de piezas: 238902, 238933, 239402, 235693, 235405, 239204, 240965. Desarrolle un dígito
de verificación para estos números mediante el uso de multiplicadores 1-3-1-3-1 y módulo 11. Use el método que
presentamos en este capítulo. ¿Por qué algunos números tienen el mismo dígito de verificación?
11. Desarrolle un sistema de dígitos de verificación para los números de piezas del problema 10; use multiplicadores 5-4-3-
2-1 y módulo 11.
12. Desarrolle un sistema de dígitos de verificación para los números de piezas del problema 10; use la fórmula de Luhn.
13. ¿Por qué un sistema de dígitos de verificación tal como 1-1-1-1-1 no funciona tan bien como otros métodos? ¿Qué
errores no detectaría?
14. Defina una expresión regular para validar cada uno de los siguientes casos:
a. Un código postal de los EE.UU., que debe tener cinco dígitos seguidos de un guión corto opcional y de otros cuatro
dígitos.
b. Un número telefónico en el formato (aaa) nnn-nnnn, en donde aaa representa el código de área y las n representan
dígitos.
c. Una fecha en la forma de día-mes-año, en donde el mes es un código de tres letras y el año es de cuatro dígitos.
Debe haber un guión corto para separar el día del mes y otro para separar el mes del año.
d. El código de derivación alfabética que se muestra en este capítulo para el suscriptor de una revista. El formato es
99999XXX9999XXX, en donde X representa a una letra y 9 representa a un número.
15. Para los siguientes códigos, defina los criterios de validación (puede haber varias verificaciones para cada campo) y el
orden en el que evaluaría cada una de las condiciones.
a. Un número de tarjeta de crédito introducido en un formulario Web: El cliente seleccionó el tipo de tarjeta de
crédito de una lista desplegable.
b. Un número de pieza en una tienda de ferretería: El número de pieza es un código complejo, en donde el primer
dígito representa el departamento (como artículos del hogar, automotriz, etcétera) y el número debería ser de
autoverificación. Hay siete departamentos distintos.
c. La fecha en que se colocó el matasellos en un libro al momento de devolverlo a una biblioteca en línea: Se
debe incluir una copia del recibo del cliente con el libro. Los libros devueltos se deben sellar en un plazo no mayor a
30 días después de la fecha de compra.
d. El código hablado de un lenguaje utilizado en un sitio Web: (Sugerencia: Busque en la Web los códigos de
lenguajes estándar.).
e. El número de licencia de un conductor, compuesto de varias partes: El mes de nacimiento de la persona, el
cumpleaños y el año de nacimiento, no necesariamente juntos; un código que representa el color de ojos y un
número de secuencia. La licencia de conductor contiene la fecha de nacimiento, el color de ojos y de pelo, así como
el nombre y dirección de la persona.
f. El código postal canadiense: El formato es X9X 9X9 (X es cualquier letra, 9 es cualquier número).
g. Códigos de equipaje de aerolíneas: Como LAX para Los Ángeles o DUB para Dublín.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 511
h. Una clave de producto utilizada para desbloquear el software comprado: La clave consiste en cuatro grupos de
cinco caracteres cada uno. El primer grupo debe tener dos letras seguidas de tres números; el segundo grupo debe
contener dos números seguidos de tres letras; el tercer grupo debe contener dos letras, cada una de la A a la G,
seguidas de tres números del uno al cuatro; y el último grupo debe contener una letra, E, G o C, dos dígitos con
valores de cuatro a siete y dos letras, ya sean A, B o C. (Sugerencia: Un patrón puede ser la mejor forma de validar
la clave del producto.).
PROYECTOS EN GRUPO
1. Lea junto con los miembros de su grupo la Oportunidad de consultoría 15.3, “Entrar o no entrar: esa es la cuestión” que
presentamos anteriormente en este capítulo. Diseñe un sistema de entrada de datos apropiado para Elsinore Industries. El
diseño de su grupo debe hacer énfasis en la eficiencia y precisión. Además, debe haber distinción entre los datos
modificables y los datos que indican la diferencia entre un elemento introducido y todos los demás. Dibuje los prototipos
de las pantallas necesarias para explicar lo que recomienda.
2. Divida su grupo en analistas y empleados de Elsinore Industries para un juego de roles. Los analistas deben presentar el
nuevo sistema de entrada de datos, completo con pantallas de prototipos. Pida a los empleados de Elsinore una
retroalimentación sobre el diseño.
3. Escriba un breve párrafo para describir cómo mejorar el diseño original de entrada de datos con base en los comentarios
recibidos.
BIBLIOGRAFÍA SELECCIONADA
Davis, G. B. y M. H. Olson, Management Information Systems, Conceptual Foundations, Structure, and Development, 2ª. Edi-
ción. Nueva York: McGraw-Hill, 1985.
Lamming, M. G., P. Brown, K. Carter, M. Eldridge, M. Flynn, G. Louie, P. Robinson y A. Sellan. “The Design of a Human
Memory Prosthesis”. Computer Journal, Vol. 37, 1994, pp. 153-163.
Lee, Y. M., F. Cheng y Y. T. Leung. “Exploring the Impact of RFID on Supply Chain Dynamics”. En Proceedings of the 2004
Winter Simulation Conference, pp. 1145-1152. Editado por R. G. Ingalls, M. D. Rossetti, J. S. Smith y B. A. Peters.
MacKay, D. J. Information Theory, Inference and Learning Algorithms. Cambridge, Reino Unido: Cambridge University Press,
2004.
Miller, G. A. “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capability for Processing Information”.
Psychological Review, Vol. 63, Núm. 2, marzo de 1956, pp. 81-97.
Newman, W. N., M. G. Lamming y M. Lamming. Interactive System Design. Reading, MA: Addison-Wesley Longman Publis-
hing Co., 1995.
Niederman, F., R. G. Mathieu, R. Morley e I. Kwon. “Examining RFID Applications in Supply Chain Management”, Commu-
nications of the ACM, Vol. 50, Núm. 7, julio de 2007, pp. 92-101.
Owsowitz, S. y A. Sweetland. “Factors Affecting Coding Errors”, Rand Memorandum RM-4346-PR. Santa Monica, CA: Rand
Corporatioin, 1965.
Robey, D. y W. Taggart. “Human Processing in Information and Decision Support Systems”. MIS Quarterly, Vol. 6, Núm. 2,
junio 1982, pp. 61-73.
Ryder, J. “Credit Card Validation Using LUHN Formula”. www.freevbcode.com. Último acceso en 26 de agosto de 2009.www.xlibros.com

512 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
E P I S O D I O 1 5
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Introducir en forma natural
El martes al mediodía Anna y Chip tienen su sesión semanal de revisión de análisis y diseño. Chip agita sus manos hacia una
gran pila de documentos que están organizados en forma ordenada en una mesa grande. “No puedo creer que casi terminemos
con el diseño de este sistema”, comenta. “Ha sido un largo proceso, pero apuesto a que obtuvimos la retroalimentación suficiente
como para asegurar un sistema de alta calidad. Todo lo que queda es el diseño de los procedimientos de entrada de datos y es-
taremos listos para empezar a empaquetar las especificaciones para los programadores”.
“Así es”, le responde Anna, “se acerca el fin. Empecemos por examinar el diseño de la porción del sistema correspondiente
a la entrada”.
“El programa AGREGAR SOFTWARE (ADD SOFTWARE) está en línea”, observa Chip. “El operador tendrá que veri-
ficar visualmente cada transacción. Después de editar todos los campos de datos para asegurar la precisión, aparecerá un men-
saje en la parte inferior de la pantalla para pedir a los operadores que verifiquen la precisión de los datos en la pantalla, los
comparen con el formulario y hagan clic en el botón Guardar registro (Save Record) si todo está correcto. Los operadores
tendrán la oportunidad de realizar cambios si los datos se teclean en forma incorrecta”.
Hay que editar cada campo de datos para mantener la precisión. Chip comenta: “A la larga es mejor editar por completo
los programas para asegurar que sean precisos, en vez de descubrir que se almacenaron los datos incorrectos en los archivos
maestros y se imprimieron en los informes”.
La estrategia para editar los campos es verificar los datos en el siguiente orden:
1. Sintaxis (si los datos son numéricos o alfabéticos) y la longitud de los datos. Un ejemplo es el NUMERO INVENTARIO
HARDWARE (HARDWARE INVENTORY NUMBER), que debe tener ocho caracteres de longitud y ser numérico.
2. El contenido del campo, incluyendo rango, límite y valores para los datos. Al validar la FECHA COMPRA (DATE PURCHA-
SED), el mes debe ser de 1 a 12. Esta verificación debe ocurrir sólo después de haber verificado que el mes sea numérico.
3. Verificaciones de referencias cruzadas entre dos o más elementos de datos. Para verificar la porción de FECHA COMPRA
correspondiente al día, se utilizará una tabla del número de días posibles en cada mes para un límite superior. Esta tabla no
se podría utilizar si el mes no estuviera entre 1 y 12. Los dígitos de verificación son otro ejemplo de una edición de refe-
rencias cruzadas.
4. Las ediciones externas, como leer un archivo para verificar si el registro que se va a agregar no existe ya en el archivo. Leer
registros es más lento que editar, lo cual se lleva a cabo en memoria principal y debe ocurrir sólo después de que los datos
pasen con éxito todas las demás pruebas de edición.
Se introdujeron los criterios de edición en la pantalla de visualización Repositorio de elementos (Element Repository)
de Visible Analyst a medida que se agregaban elementos al diseño. Estos elementos incluyen criterios de edición simples y
verificación de tablas. Se puede usar el área Notas (Notes) para introducir criterios de edición. La entrada NUMERO INVEN-
TARIO HARDWARE (HARDWARE INVENTORY NUMBER) incluye una referencia para usar el método módulo 11 de
verificar la porción del número correspondiente al dígito de verificación. Además, al agregar una nueva computadora, hay que
leer el archivo MAESTRO DE COMPUTADORAS para asegurar que no exista ya un registro con el mismo NUMERO INVEN-
TARIO HARDWARE.
Varios elementos tienen áreas de Notas referentes a las tablas, así como entradas para los códigos en el área Valores y
significados (Values and Meanings). Un ejemplo es el elemento SISTEMA OPERATIVO (OPERATING SYSTEM). “Produ-
ciré una lista de las tablas que vamos a requerir”, ofrece Anna. Para producir la lista hay que buscar en la página Web Reposi-
torio (Repository) o usar la herramienta Consulta de informes (Report Query) de Visible Analyst. Se imprimirá una lista de
todos los elementos que contienen notas empezando con “Tabla de códigos (Table of codes)”. En la lista se incluyen Imagen
(Picture) y Longitud (Length) para mostrar la sintaxis del código. Con esta lista se crean tablas.
Cada tabla de códigos se define mediante tablas de Microsoft Access. Chip y Anna pasan tiempo trabajando en las tablas. Se
selecciona un código mnemónico para SISTEMA OPERATIVO y para representar la CATEGORIA SOFTWARE (SOFTWARE
CATEGORY) debido a que facilita el trabajo a los usuarios. “Creo que un esquema de codificación de subconjunto de dígitos
significativos sería el mejor para codificar los edificios del campus”, comenta Chip. Anna está de acuerdo. “Eso es bueno, Chip. El
primer dígito para la ubicación del campus y los otros dos dígitos para representar edificios individuales en el campus”.
Chip diseña los códigos utilizados para la tabla SISTEMA OPERATIVO. La pantalla de Microsoft Access se muestra en
la figura E15.1. Se utilizan dos columnas para definir los códigos. La columna izquierda contiene el código y la columna dere-
cha contiene su significado. Esas entradas se pueden modificar y es posible agregar nuevas entradas, con lo cual se obtiene
flexibilidad en el sistema final.
“He aquí la tabla CATEGORIA SOFTWARE que creé”, dice Anna. “Esta tabla se puede actualizar con facilidad, a medida
que la universidad desarrolle y adquiera nuevo software. Es sorprendente la rapidez con la que puede cambiar el software”.
“Ése es un valioso componente del sistema”, comenta Chip. “Provee consistencia para todos los códigos y sus significados”.
Chip y Anna terminan su trabajo la siguiente mañana aproximadamente a las 11:30. Miran felizmente alrededor de la sala
y vuelven a examinar con frecuencia el diseño final. Finalmente terminan los meses de análisis, trabajo de diseño, consultas con
los usuarios y una cuidadosa adherencia a los estándares.
“Me siento realmente bien con este proyecto”, dice Anna.
Chip asiente, “Estoy orgulloso de la calidad que aportamos”.www.xlibros.com

CAPÍTULO 15 • DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS 513
FIGURA E15.1
TABLA DE CODIGOS
SISTEMA OPERATIVO
(OPERATING SYSTEM TABLE
OF CODES) definida mediante
Microsoft Access.
EJERCICIOS
E-1. Modifique e imprima los siguientes elementos con criterios de edición en el área Notas (o Valores y significados para
códigos específicos). Puede encontrarlos en la página Web Repositorio o en el repositorio de Visible Analyst.
E-2. Modifique e imprima los siguientes elementos con los criterios de edición colocados en el área Notas:
Elemento Criterio de edición
a. CATEGORIA SOFTWARE Tabla de códigos:
Código Categoría Software (Software Category Code)
b. CODIGO NIVEL CAPACITACION CURSO
(COURSE TRAINING LEVEL CODE)
B - Principiante; I - Intermedio;
A - Avanzado
c. SISTEMA OPERATIVO (OPERATING SYSTEM) W - Windows Vista Ultimate;
B - Windows Vista Business;
U - Unix
a. Elemento: NUMERO INVENTARIO SOFTWARE (SOFTWARE INVENTORY
NUMBER)
Notas: Hay que verificar un dígito de verificación módulo 11 al introducir el
número. El programa AGREGAR SOFTWARE (ADD SOFTWARE) crea
el dígito de verificación.
El programa AGREGAR SOFTWARE también debe verificar el archivo
MAESTRO DE SOFTWARE (SOFTWARE MASTER) para asegurar que
no exista ya un registro con el mismo número de inventario.
b. Elemento: FECHA COMPRA (DATE PURCHASED)
Notas: Verificar que FECHA COMPRA sea menor o igual que la fecha actual.
c. Elemento: CANTIDAD RECIBIDA (QUANTITY RECEIVED)
Notas: Verificar que CANTIDAD RECIBIDA sea menor o igual que CANTIDAD
ORDENADA (QUANTITY ORDERED).
d. Elemento: VERSION ACTUALIZACION SOFTWARE (SOFTWARE UPGRADE
VERSION)
Notas: Asegurar que VERSION ACTUALIZACION (UPGRADE VERSION) sea
mayor que la versión actual.
e. Elemento: SEGUNDO DISCO DURO (SECOND HARD DRIVE)
Notas: SEGUNDO DISCO DURO sólo puede existir si hay una entrada para
DISCO DURO (HARD DRIVE).www.xlibros.com

514 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
1 Campus Central
2 Campus Waterford
3 Campus Hillside
E-3. Después de hablar con Dot Matricks y Mike Crowe, es aparente que los códigos del campus deben tener capacidad de
ordenamiento para instalar hardware y software, así como para crear hojas de inventario. Use Microsoft Access para
modificar e imprimir la tabla CODIGOS UBICACION CAMPUS (CAMPUS LOCATION CODES). El primer dígito
representa la ubicación del campus. Los valores son los siguientes:
Los siguientes tres dígitos representan los edificios en el campus, con los siguientes códigos de edificios:
Use una combinación (de su elección) de códigos y edificios del campus para construir la tabla final de códigos. Incluya
el significado del código.
Los ejercicios en los que se antepone un icono www indican material de valor agregado disponible en el sitio Web www.pearsonhighered.com/
kendall. Los estudiantes pueden descargar un archivo de ejemplo de Microsoft Visio, Visible Analyst, Microsoft Project o Microsoft Access que
pueden usar para completar los ejercicios.
001 Administración
002 Admisiones
003 Agricultura
004 Astronomía
005 Negocios
006 Ingeniería Química
007 Ciencias Computacionales
008 Educación
009 Ingeniería
010 Estudios Ambientales
011 Geología
012 Leyes
013 Biblioteca
014 Matemáticas
015 Medicina
016 Física
017 Psicología
018 Zoologíawww.xlibros.com

515
C A P Í T U L O 1 6
Aseguramiento e
implementación de la calidad
OBJETIVOS DE APRENDIZAJE
Al completar este capítulo usted podrá:
1. Reconocer la importancia de los usuarios y analistas que asumen el enfoque de calidad
total para mejorar la calidad del diseño y mantenimiento del software.
2. Comprender la importancia de los procesos de documentación, prueba, mantenimiento y
auditoría.
3. Entender cómo la arquitectura orientada a los servicios y la computación en nube están
cambiando la naturaleza del diseño de sistemas de información.
4. Diseñar programas de capacitación apropiados para usuarios del nuevo sistema.
5. Reconocer las diferencias entre las estrategias de conversión físicas; recomendar una
apropiada para un cliente.
6. Abordar cuestiones de seguridad, preparación para desastres y recuperación de desastres
para los sistemas tradicionales y basados en Web.
7. Comprender la importancia de evaluar el nuevo sistema y recomendar una técnica de
evaluación adecuada a un cliente.
Desde hace tiempo, las empresas se preocupan por la calidad de la misma
forma en que los analistas de sistemas se preocupan por el análisis y diseño
de los sistemas de información. El usuario del sistema de información es el
factor individual más importante para establecer y evaluar su calidad. Es
mucho menos costoso corregir problemas en las primeras etapas que esperar
a que un problema genere crisis o quejas de los usuarios. Los tres métodos
para el aseguramiento de calidad a través de la ingeniería de software son: 1) afianzar un asegu-
ramiento de calidad total al diseñar sistemas y software con una metodología modular descen-
dente (arriba-abajo o
top-down); 2) documentar el software con las herramientas apropiadas,
y 3) probar, mantener y realizar auditorías en el software.
Al proceso de asegurar que el sistema de información sea funcional y después permitir a los
usuarios hacerse cargo de su operación para usarlo y evaluarlo se le conoce como implementación.
Este proceso implica ceder el poder de cómputo y la responsabilidad a los usuarios de la empresa
mediante la ayuda de la computación distribuida, la computación en nube y la arquitectura orien-
tada a servicios; también involucra la capacitación de los usuarios y asegurar que cada uno de
ellos comprenda sus nuevos roles dentro del nuevo sistema de información. Adicionalmente, la
implementación abarca la elección de una estrategia de conversión, proveer las medidas apropia-
das de seguridad, privacidad y planes contra desastres, y la evaluación del sistema de información
nuevo o modificado.www.xlibros.com

516 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
LA METODOLOGÍA DE ADMINISTRACIÓN DE LA CALIDAD TOTAL
La administración de la calidad total (TQM) es esencial en todos los pasos de desarrollo de sistemas. De acuerdo
con Evans y Lindsay (2004), los principales elementos de la TQM tienen sentido sólo cuando ocurren en un con-
texto organizacional que apoye un esfuerzo de calidad integral. Es en este contexto en el que se unen los elemen-
tos de enfoque hacia el cliente, la planeación y el liderazgo estratégico, la mejora continua, el otorgamiento de
poderes y el trabajo en equipo para cambiar el comportamiento de los empleados y, en última instancia, el curso
de la organización. Cabe mencionar que el concepto de calidad se ha ampliado a través de los años para reflejar
un enfoque organizacional que no está orientado exclusivamente a la producción. En vez de concebir la calidad
como el control del número de productos defectuosos producidos, ahora se considera como un proceso evolutivo
hacia la perfección, al cual se le conoce como administración de la calidad total.
Los analistas de sistemas deben estar conscientes de los factores que impulsan el interés en la calidad. Es
importante tener en cuenta que el compromiso cada vez mayor de las empresas con la TQM se adapta extraordi-
nariamente bien a los objetivos generales para el análisis y diseño de sistemas.
Seis Sigma
La llegada de Seis Signa modificó el enfoque hacia la administración de la calidad. Los analistas de sistemas y
los usuarios de los sistemas necesitan estar conscientes de la existencia de Seis Sigma y aplicar algunos de los
principios a sus proyectos de análisis de sistemas. La metodología Seis Sigma, desarrollada originalmente por
Motorola en la década de 1980, es algo más que una metodología; es una cultura que se basa en la calidad. El
objetivo de Seis Sigma es eliminar todos los defectos y se aplica a cualquier producto, servicio o proceso. En los
libros de texto de administración de operaciones, desde la década de 1970 hasta finales de siglo, el control de
calidad se expresaba en términos de tres derivaciones estándar de la media, o tres sigma, lo cual equivale a cerca
de 67,000 defectos por millón de oportunidades. Seis Sigma implica un objetivo de no más de 3.4 defectos por
millón de oportunidades.
Seis Sigma es una metodología descendente. Es necesario que un CEO adopte la filosofía y que un ejecutivo
sirva como campeón del proyecto. Al líder de un proyecto Seis Sigma se le denomina Cinta Negra (la metáfora
de Cinta Negra proviene del sistema de clasificación de capacidades en las artes marciales). Los Cintas Negras
se certifican después de haber dirigido proyectos con éxito. A los demás miembros del equipo se les denomina
Cintas Verdes. Las Cintas Negras son Cintas Verdes que han trabajado en muchos proyectos y están disponibles
como recurso para los equipos de los proyectos.
Podemos sintetizar a Seis Sigma como una metodología (la figura 16.1 muestra los pasos de Seis Sigma);
sin embargo, es mucho más que sólo eso: es una filosofía y una cultura. Para obtener más información sobre Seis
Sigma y la administración de la calidad, visite el sitio Web del Juran Center en la Carlson School of Management,
University of Minnesota, Twin Cities (ww.csom.umn.edu). En 2002 el Juran Center emitió una declaración de
apoyo y fomento de la calidad. Los autores de este libro firmamos el estatuto en ese entonces y estamos comple-
tamente de acuerdo en sus principios.
El desaparecido Joseph M. Juran dijo: “Toda mejora de la calidad ocurre proyecto tras proyecto y de nin-
guna otra manera” (Juran, 1964). Los analistas de sistemas, los gerentes de proyectos y los usuarios deberían
tomar esto muy en serio.
Responsabilidad de la administración de la calidad total
Hablando en específico, gran parte de la responsabilidad por la calidad de los sistemas de información recae
en los usuarios del sistema y la gerencia. Deben ocurrir dos cosas para que la TQM se convierta en una realidad con
los proyectos de sistemas. En primer lugar debe existir el soporte organizacional completo de la gerencia, algo
considerablemente distinto al simple hecho de promocionar el ardid administrativo más reciente. Dicho soporte
implica establecer un contexto para que el personal administrativo considere con seriedad cómo afecta la calidad
tanto de la información como de los sistemas de información en su trabajo.
Es necesario que el analista y los usuarios de la empresa se comprometan con la calidad lo antes posible
para lograr el objetivo de ésta. Este compromiso se ejerce como resultado de un esfuerzo de ritmo uniforme hacia
la calidad en todo el ciclo de vida de desarrollo de sistemas; además supone un fuerte contraste con el hecho de
tener que invertir mucho esfuerzo para resolver los problemas al final del proyecto.
Para lograr el apoyo de la organización en relación con la calidad en los sistemas de información administra-
tivos, debemos proveer tiempo laboral para los círculos de calidad de sistemas de información (IS), que consisten
en seis a ocho colegas de la organización, cada uno con la responsabilidad específica de definir cómo mejorar los
sistemas de información y cómo implementar las mejoras.
A través del trabajo en los círculos de calidad de IS o por medio de otros mecanismos en operación, la ge-
rencia y los usuarios deben desarrollar lineamientos para los estándares de calidad de los sistemas de informa-www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 517
FIGURA 16.1
Todo analista de sistemas debe
comprender la metodología y
filosofía de Seis Sigma.
ción. Es preferible que se reestructuren los estándares cada vez que el equipo de análisis de sistemas proponga
formalmente un nuevo sistema o una modificación importante al sistema actual.
No es fácil elaborar estándares, pero es posible y ya se ha hecho antes. Parte del trabajo del analista de siste-
mas es alentar a los usuarios a cristalizar sus expectativas sobre los sistemas de información y sus interacciones
con éstos.
Después es necesario comunicar los estándares de calidad departamentales por medio de la retroalimenta-
ción para el equipo de análisis de sistemas. A menudo, el equipo se sorprende de lo que se ha desarrollado. Por lo
general las expectativas son menos complejas de lo que los analistas experimentados saben que se podría hacer
con un sistema. Además, cabe la posibilidad de que las cuestiones humanas que el equipo de analistas pasó por
alto o subestimó se consideren mucho muy urgentes en los estándares de calidad de los usuarios. Al hacer que
los usuarios se involucren en delinear los estándares de calidad para los sistemas de información, el analista po-
drá evitar costosos errores en el desarrollo de sistemas no deseados o innecesarios.
Recorrido estructurado
Una de las acciones administrativas de calidad más robusta que el equipo de análisis de sistemas puede llevar
a cabo es realizar recorridos estructurados de manera rutinaria. Los recorridos estructurados son una manera de
usar colegas revisores para que supervisen la programación del sistema y su desarrollo en general, señalen los
problemas y permitan que el programador o analista responsable de esa parte del sistema realicen las modifica-
ciones apropiadas.
Los recorridos estructurados involucran por lo menos a cuatro personas: la persona responsable de la parte
del sistema o subsistema que se va a revisar (un programador o analista), un coordinador del recorrido, un colega
programador o analista y un colega que haga las anotaciones sobre sugerencias.
Cada persona que asiste a un recorrido tiene que desempeñar un papel especial. El coordinador está ahí
para asegurar que los otros se adhieran a los roles que tienen asignados y para asegurar que se realicen todas las
actividades programadas. El programador o analista está ahí para escuchar y no para defender su opinión, racio-
nalizar un problema o argumentar. El colega programador o analista está presente para señalar los errores o pro-
blemas potenciales, no para especificar cómo se deberían corregir. El que toma notas registra lo que se dice, de
manera que los otros presentes puedan interactuar sin ningún impedimento.
Los recorridos estructurados se adaptan bien en una metodología de administración de la calidad total cuando
se realizan en todo el ciclo de vida del desarrollo de sistemas. El tiempo que requieren debe ser poco (entre me-
6
Estandarizar los
cambios
3
Analizar las
causas
1
Definir el
problema
7
Sacar
conclusiones
2
Observar el
problema
Seis Sigma
4
Actuar en base
a las causas
5
Estudiar los
resultadoswww.xlibros.com

518 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
dia y una hora a lo más), lo cual significa que deben estar bien coordinados. La figura 16.2 muestra un formula-
rio útil para organizar el recorrido estructurado e informar sus resultados. Como los recorridos toman tiempo, no
es conveniente abusar de ellos.
Usar recorridos estructurados es una forma de obtener (y después actuar con base en) una valiosa retroali-
mentación desde una perspectiva que no tenemos nosotros. Al igual que con todas las medidas de aseguramiento
de calidad, el objetivo de los recorridos es evaluar el producto de manera sistemática en forma continua, en vez de
esperar a que se complete el sistema.
Diseño y desarrollo de sistemas descendente
Muchas empresas introdujeron primero los sistemas de cómputo en el nivel más bajo de la organización. Ahí es
donde se puede observar mejor los beneficios inmediatos de la computarización, además de que son más efectivos
en costo. A menudo, las empresas asumen este enfoque en el desarrollo de sistemas al adquirir, por ejemplo, soft-
ware COTS para contabilidad, un paquete distinto para la calendarización de producción y otro para marketing.
Cuando se termina la programación interna con una metodología ascendente (abajo-arriba o bottom-up), es
difícil interconectar los subsistemas de manera que funcionen uniformemente como un sistema. Cuesta mucho
corregir los errores de interfaz y muchos de ellos no se descubren sino hasta que se completa la programación,
cuando los analistas tratan de cumplir con una fecha de entrega al ensamblar todo el sistema. En este punto hay
poco tiempo, presupuesto o paciencia por parte del usuario para la depuración de las delicadas interfaces que se
ignoraron.
Aunque cada pequeño subsistema parece obtener el software funcional que necesita, al considerar todo el
sistema hay varias limitaciones con respecto a la metodología descendente. Una de ellas es que se duplica el es-
fuerzo en la compra del software e incluso al introducir los datos. Otra es que se introducen datos sin valor en el
sistema. La tercera desventaja (y tal vez la más grave) de la metodología descendente es que, aunque se hayan
cumplido muchas de las necesidades de los usuarios, no se están considerando los objetivos de la organización
en general y, por ende, no se pueden cumplir.
El diseño descendente permite al analista de sistemas establecer primero los objetivos de la organización,
además de establecer cómo se deben cumplir de la mejor manera en un sistema en general. Después el analista
divide ese sistema en subsistemas y sus requerimientos.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 6 . 1
La calidad de MIS no se pone a prueba
“Merle, ven aquí y echa un vistazo a estos informes de fin de
semana”, suplica Portia. Como una de los gerentes en la fuerza de tra-
bajo de IS/comité de aseguramiento de calidad de seis personas,
Portia ha estado analizando para su departamento de marketing la
salida del sistema que el prototipo ha estado produciendo. El equipo
de analistas de sistemas le pidió que revisara la salida.
Merle Chant camina hacia el escritorio de Portia y da un vistazo
a los folletos informativos que Portia sostiene. “¿Por qué, qué está
mal?”, pregunta. “A mí me parecen bien. Creo que estás tomando
demasiado a pecho esto de la fuerza de trabajo. Se supone que debe-
mos realizar también nuestro otro trabajo, ¿no?”. Merle voltea y re-
gresa a su escritorio ligeramente perturbado por la interrupción.
“Ten un poco de piedad, Merle. Realmente es ridículo aguan-
tar estos informes así como están. No puedo encontrar nada de lo
que necesito y se supone que debo decir a todos los demás en el
departamento qué parte del informe deben leer. Estoy decepcio-
nada. Este informe no sirve. No tiene ningún sentido para mí. Es un
refrito de la salida que estamos obteniendo ahora. En realidad, se ve
peor. Voy a llevar esto a la siguiente reunión de la fuerza de trabajo”,
Portia proclama con insistencia.
Merle voltea a verla y dice: “La calidad es su responsabilidad,
Portia; si el sistema no nos da buenos informes, lo corregirán a la
hora de implementarlo. Todo lo que estás haciendo es causar con-
troversia. Actúas como si en realidad tomaran en cuenta nuestra
entrada. No les daría la hora del día, mucho menos haría su trabajo
por ellos. Son muy inteligentes, déjalos que averigüen lo que nece-
sitamos”.
Portia mira a Merle sin expresión y después empieza a eno-
jarse un poco. “Hemos estado en la fuerza de trabajo por cuatro
semanas”, dice. “Estuviste en cuatro reuniones. Somos los que co-
nocen el negocio. La idea en sí de la TQM es decirles lo que nece-
sitamos, con qué estamos satisfechos. Si no les decimos lo que
necesitamos, entonces no nos podemos quejar. Mencionaré esto la
próxima vez que nos reunamos”.
¿Qué tan efectivo cree que será Merle para comunicar sus es-
tándares de calidad al equipo de análisis de sistemas y a los miem-
bros de la fuerza de trabajo de IS? Responda en un párrafo. Si los
analistas de sistemas pueden percibir la falta de voluntad de Merle
para trabajar con la fuerza de trabajo en el desarrollo de estándares
de calidad, ¿qué diría para convencerlo de la importancia de la
participación de los usuarios en la TQM? Haga una lista de argu-
mentos que soportan el uso de TQM. ¿Cómo puede responder el
equipo de análisis de sistemas a los problemas que Portia está cues-
tionando? Diseñe una respuesta en un párrafo.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 519
Informe para la gerencia sobre
el recorrido estructurado
Nombre del proyecto:
Firma del coordinador:
Fecha en que se presentó
el informe: / /
Número de proyecto:
Fecha del recorrido: / /
Hora:
Coordinador del recorrido:
Lista de participantes:
Comentarios:
Acción recomendada (marque una):
( ) ACEPTAR TRABAJO COMO ESTÁ
( ) REVISAR TRABAJO
( ) REVISAR TRABAJO Y REALIZAR
RECORRIDO DE SEGUIMIENTO
( ) RECHAZAR TRABAJO
Porción (descripción) del trabajo que se examinó:
FIGURA 16.2
Un formulario para documentar
recorridos estructurados; es
posible realizar recorridos cada
vez que se completa una porción
de código, un sistema o un
subsistema.
El diseño descendente es compatible con el pensamiento sobre sistemas generales que vimos en el capítulo 2.
Cuando los analistas de sistemas emplean una metodología descendente, están pensando en las interrelaciones e
interdependencias de los subsistemas y la manera en que se adaptan a la organización existente. La metodología
descendente también provee un conveniente énfasis en la sinergia o las interfaces que requieren los sistemas y
sus subsistemas, lo cual no es posible en la metodología ascendente. Esto ayuda a responder la pregunta sobre
cuántos equipos deben trabajar juntos para lograr sus metas.
Una de las ventajas de utilizar una metodología descendente para el diseño de sistemas es evitar el caos de
tratar de diseñar un sistema todo a la vez. Como hemos visto, el proceso de planeación e implementación de sis-
temas de información administrativa es increíblemente complejo. Tratar de implantar todos los subsistemas y
ejecutarlos al mismo tiempo es la vía más directa al fracaso.
Una segunda ventaja de la metodología descendente en el diseño es que permite a los equipos separados de
análisis de sistemas trabajar en paralelo en subsistemas distintos pero necesarios, lo cual puede ahorrar mucho
tiempo. El uso de equipos para el diseño de subsistemas se adapta muy bien de manera específica a una metodo-
logía de aseguramiento de calidad total.www.xlibros.com

520 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Una tercera ventaja es que la metodología descendente evita un problema importante asociado con la meto-
dología ascendente: evita que los analistas de sistemas se enreden tanto en los detalles que pierdan la visión de lo
que se supone debe hacer el sistema.
La administración de calidad total y la metodología descendente para el diseño pueden ir de la mano. La
metodología descendente provee al grupo de sistemas una división preparada de usuarios en fuerzas de trabajo
(equipos especializados de usuarios) para los subsistemas. Las fuerzas de trabajo que se establecen de esta forma
pueden cumplir entonces una doble función como círculos de calidad para el sistema de información adminis-
trativa. De esta manera se establece la estructura necesaria para el aseguramiento de la calidad, al igual que la
motivación apropiada para hacer que el subsistema logre las metas departamentales que son importantes para los
usuarios involucrados.
Uso de diagramas de estructura para diseñar sistemas modulares
Una vez que nos decidimos por la metodología de diseño descendente, es conveniente usar una metodología
modular para la programación. Esta metodología implica descomponer la programación en porciones lógicas y
manejables, o módulos. Este tipo de programación funciona bien con el diseño descendente, ya que enfatiza las
interfaces entre los módulos y no las hace a un lado hasta etapas posteriores en el desarrollo de sistemas. Lo ideal
es que cada módulo individual sea funcionalmente cohesivo, de manera que tenga que realizar sólo una función.
El diseño de programas modulares tiene tres ventajas principales. En primer lugar, los módulos son más
fáciles de escribir y depurar debido a que son prácticamente independientes. Es menos complicado rastrear un
error en un módulo, ya que no debería causar problemas en los demás.
A T R A C T I V O D E L A M A C
A un analista que necesite completar un recorrido estructurado le podría convenir utilizar Things, una aplicación para
el iPhone de Apple. Cuando los analistas regresan a su oficina, pueden descargar la información en su versión de escri-
torio. Things es simplemente otra forma de organizarse, pero es mucho más simple que OMNI-focus (que vimos en otra
sección del libro).
FIGURA 16.MAC
Things de Cultured Code.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 521
Una segunda ventaja del diseño modular es que los módulos son más fáciles de mantener. Por lo general, las
modificaciones se limitan a unos cuantos módulos y no se diseminan en todo un programa.
Una tercera ventaja del diseño modular es que los módulos son más fáciles de comprender, ya que son sub-
sistemas independientes. Por ende, un lector puede elegir un listado de código de un módulo y comprender su
función.
A continuación le mostramos algunos lineamientos para la programación modular:
1. Mantener cada módulo en un tamaño manejable (lo ideal es que sólo incluya una función).
2. Poner atención especial en las interfaces críticas (los datos y las variables de control que se pasan a otros
módulos).
3. Minimizar el número de módulos que debe modificar el usuario al realizar cambios.
4. Mantener las relaciones jerárquicas establecidas en las fases de la metodología descendente.
La herramienta recomendada para diseñar un sistema modular descendente se denomina diagrama de estructura;
consiste en cuadros rectangulares que representan a los módulos, junto con flechas para conectarlos.
La figura 16.3, un conjunto de módulos que se utilizan para modificar el registro de un cliente, muestra siete
módulos identificados como 000, 100, 110, 120, etcétera. Los módulos de nivel más alto se identifican con los
números de 100 en adelante y los de nivel más bajo, con números de 10 hasta antes del 100. Esta numeración
permite a los programadores insertar módulos utilizando un número entre los números de módulos adyacentes.
Por ejemplo, si insertamos un módulo entre los módulos 110 y 120 le asignaríamos el número 115.
En los extremos de las líneas conectoras se dibujan dos tipos de flechas. Las flechas con los círculos sin
relleno se denominan acoplamientos de datos y las flechas con los círculos rellenos se denominan banderas de
control o interruptores. Un interruptor es lo mismo que una bandera de control, excepto porque se limita a dos
valores: sí o no. Estas flechas indican que se transmite algo, ya sea hacia el módulo inferior o hacia el superior.
En teoría, el analista debería mantener este acoplamiento de datos en el mínimo posible. Entre menos puntos
de acoplamiento de datos y banderas de control tenga uno en el sistema, más fácil será modificarlo. Al momento de
empezar a programar estos módulos es importante pasar el menor número de puntos de acoplamiento de datos
entre los módulos.
Lo que es incluso más importante es evitar usar demasiadas banderas de control. El control está diseñado
para transmitirse de los módulos de nivel más bajo a los de nivel más alto en la estructura; en raras ocasiones
será necesario transmitir el control hacia abajo en la estructura. Cuando se pasa el control hacia abajo, se permite
a un módulo de nivel bajo tomar una decisión y el resultado es un módulo que realiza dos tareas distintas, lo que
viola el ideal de un módulo funcional: sólo debe realizar una tarea.
000
Modificar archivo
maestro de
clientes
100
Modificar
registro de
cliente
130
Imprimir línea de
error de cliente
no encontrado
140
Dar formato a
nuevo archivo
maestro de clientes
150
Reescribir archivo
maestro de
clientes
120
Leer archivo
maestro de
clientes
110
Leer modificar
transacción
cliente
Archivo
maestro de
cliente
modificado
Archivo
maestro de
cliente
modificado
Archivo maestro
de cliente
Archivo maestro
de cliente
Número de
cliente
Número de
cliente
Interruptor de
registro encontrado
Modificar
registro transacción
Interruptor
de fin de
archivo
Modificar
registro
trans.
FIGURA 16.3
Un diagrama de estructura
fomenta el diseño descendente
mediante el uso de módulos.www.xlibros.com

522 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Servicios basados en Web
Servicios basados en empresas
Los módulos de aplicaciones que conforman un sistema
FIGURA 16.4
Los módulos en las arquitecturas
orientadas al servicio son
independientes y pueden ser
omnipresentes.
Incluso cuando un diagrama de estructura logra todos los fines para los cuales se dibujó, no puede permane-
cer como la única técnica de diseño y documentación. En primer lugar, no muestra el orden en el que se deben
ejecutar los módulos (un diagrama de flujo de datos se encarga de eso); en segundo, no muestra el suficiente de-
talle (el español estructurado se encarga de eso).
Arquitectura orientada a servicios (SOA)
El desarrollo modular ha originado un concepto denominado arquitectura orientada a servicios (SOA), el cual es
muy distinto a los módulos en el diagrama de estructura. En vez de ser jerárquica como la metodología descen-
dente de los diagramas de estructura, la metodología SOA se encarga de crear servicios SOA individuales que no
tengan ninguna asociación o estén débilmente acoplados entre sí.
Cada servicio ejecuta una acción. Un servicio puede devolver el número de días en este mes; otro indica si el
presente es un año bisiesto; un tercer servicio puede reservar cinco noches en un cuarto de hotel, desde finales de
febrero hasta principios de marzo. Aunque el tercer servicio necesita conocer los valores que se obtienen del pri-
mero y segundo, son independientes unos de otros. Podemos usar cada uno de los servicios en otras aplicaciones
dentro de la organización, o incluso en otras organizaciones.
Podemos decir que la arquitectura orientada a servicios es sólo un grupo de servicios a los cuales podemos
llamar para que provean funciones específicas. En vez de incluir llamadas a otros servicios, un servicio puede
usar ciertos protocolos definidos para poder comunicarse con otros.
La figura 16.4 muestra cómo se hacen llamadas a los servicios en todo el sistema. Los servicios pueden ser
generales en naturaleza y se pueden externalizar, o incluso pueden estar disponibles en Web. Otros servicios son
más especializados y orientados hacia la empresa en sí. Estos servicios para empresas proveen reglas de negocios
y también pueden diferenciar a una empresa de otra. Se pueden hacer llamadas a los servicios en un momento
dado y en repetidas ocasiones en muchos módulos de aplicaciones.
La carga de conectar los servicios de una forma útil es un proceso denominado orquestación, y depende del
diseñador de sistemas. Para lograr esto podemos incluso seleccionar servicios de un menú y supervisarlos me-
diante un tablero de control SOA.
Para poder establecer una SOA, los servicios deben cumplir con los siguientes requisitos:
1. Ser modulares.
2. Ser reutilizables.
3. Trabajar en conjunto con otros módulos (interoperabilidad).
4. Ser capaces de clasificarse e identificarse.
5. Debe ser posible supervisarlos.
6. Cumplir con los estándares específicos de la industria.
Aunque las ventajas de reutilización e interoperabilidad son obvias, la SOA presenta sus retos. Primero que
nada, hay que acordar los estándares industriales. Después hay que mantener una biblioteca para que los desarro-www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 523
lladores puedan buscar los servicios que necesitan. Por último, la seguridad y la privacidad pueden presentar pro-
blemas al utilizar software desarrollado por alguien más. Los defensores de la SOA afirman que la arquitectura
orientada a servicios ha hecho posibles muchas de las características que se encuentran en la Web 2.0.
METODOLOGÍAS DE DOCUMENTACIÓN
El esfuerzo de aseguramiento de calidad total requiere que los programas tengan una documentación apropiada.
Hay que documentar el software, los sistemas y los procedimientos tanto formales como informales, de manera
que se pueda dar mantenimiento a los sistemas y mejorarlos. La documentación permite a los usuarios, progra-
madores y analistas “ver” el sistema, su software y procedimientos sin tener que interactuar con él.
La rotación del personal de servicios de información ha sido tradicionalmente alta en comparación con otros
departamentos, por lo que es probable que las personas que idearon e instalaron el sistema original no sean las
mismas que le den mantenimiento. Una documentación consistente y bien actualizada reduce el número de horas
requeridas para que el nuevo personal aprenda a usar el sistema antes de realizar un mantenimiento.
Hay muchas razones por las que los sistemas y programas no se documentan o cuentan con muy poca docu-
mentación. Algunos de los problemas residen en los sistemas y programas en sí; otros, en los analistas y progra-
madores.
Los analistas de sistemas tal vez no documenten los sistemas de manera apropiada por falta de tiempo o
de una compensación suficiente por el tiempo invertido en esta tarea; algunos no lo hacen por aversión y otros
piensan que no es su verdadero trabajo. Además, muchos analistas se muestran reticentes a documentar siste-
mas que no sean de ellos, tal vez por temor a las represalias si incluyen material incorrecto sobre el sistema
de alguien más. Los defensores de la metodología SDLC nos recuerdan que la documentación que se lleva a
cabo mediante una herramienta CASE durante las fases de análisis puede hacer frente a muchos de estos pro-
blemas.
Manuales de procedimientos
Los manuales de procedimientos son documentos comunes en las organizaciones; la mayoría de las personas los
han visto. Son el componente en español de la documentación, aunque también pueden contener, por ejemplo,
códigos de programas y diagramas de flujo. Los manuales tienen el objetivo de comunicarse con quienes los
utilizan y contienen comentarios sobre antecedentes, los pasos requeridos para realizar distintas transacciones,
instrucciones sobre cómo recuperarse de los problemas y qué se puede hacer si algo no funciona (diagnóstico de
fallas). Muchos manuales están disponibles en línea, y en hipertexto para facilitar su uso.
También es conveniente tener una metodología sencilla y estandarizada para crear documentación de soporte
para los usuarios. Para ser útil, la documentación del usuario se debe mantener actualizada. El uso de la Web ha
revolucionado la velocidad con la que los usuarios pueden obtener ayuda. Muchos desarrolladores de software
han desplazado el soporte para los usuarios (junto con los manuales, páginas FAQ, chat en línea y comunidades
de usuarios) a la Web.
Las secciones clave de un manual son una introducción, cómo usar el software, qué hacer si las cosas salen
mal, una sección de consulta técnica, un índice e información sobre cómo ponerse en contacto con el fabricante.
Las mayores quejas con los manuales de procedimientos son que: 1) están mal organizados, 2) es difícil encontrar
información en ellos, 3) el caso específico en cuestión no aparece en el manual y 4) el manual no está escrito en
español común.
El método FOLKLORE
FOLKLORE es una técnica de documentación de sistemas que se creó para complementar algunas de las técni-
cas que hemos visto. Incluso con la plétora de técnicas disponibles, muchos sistemas están mal documentados o
no cuentan con ningún tipo de documentación. FOLKLORE recopila la información que comparten comúnmente
los usuarios pero que raras veces escriben.
FOLKLORE se desarrolló por primera vez en la década de 1980 por Kendall y Losee, mucho antes de la
creación de blogs y comunidades de usuarios. FOLKLORE tiene dos ventajas principales en comparación con
las comunidades de usuarios que se encuentran comúnmente: 1) es estructurado, lo cual produce una documenta-
ción más completa y organizada, y 2) anima a que alguien familiarizado con el software busque información en
vez de dejar que los usuarios avancen por su cuenta.
FOLKLORE es una técnica sistemática basada en los métodos tradicionales utilizados para recopilar el fol-
klore sobre las personas y leyendas. En esta metodología para la documentación de sistemas, el analista tiene
que entrevistar a los usuarios, investigar la documentación existente en los archivos y observar el procesamiento
de información. El objetivo es recopilar la información correspondiente a una de cuatro categorías: costumbres,
relatos, dichos y formas artísticas. La figura 16.5 sugiere cómo se relaciona cada categoría con la documentación
de sistemas de información.www.xlibros.com

524 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Al documentar las costumbres, el analista (u otro folklorista) trata de capturar por escrito lo que están ha-
ciendo los usuarios para ejecutar todos los programas sin problemas. Un ejemplo de una costumbre sería: “Por lo
general nos tardamos dos días en actualizar los registros mensuales debido a que la tarea es bastante extensa. Nos
encargamos de las cuentas comerciales el primer día y guardamos las demás para el siguiente”.
Los relatos son historias que cuentan los usuarios en relación con la forma en que trabajó el sistema. Desde
luego que la precisión del relato depende de la memoria del usuario y es a lo más una opinión sobre la manera en
que operó el programa. Por lo general los relatos tienen un principio, una parte media y un final. Así, tendríamos
una historia sobre un problema (el principio), una descripción de los efectos (la parte media) y la solución (el final).
Los dichos son declaraciones breves que representan generalizaciones o consejo. Tenemos muchos dichos en
la vida diaria, como “Más vale malo por conocido que bueno por conocer” o “Todo cabe en un jarrito sabiéndolo
acomodar”. En la documentación de sistemas tenemos también muchos dichos, como “Omita esta sección de có-
digo y el programa explotará” o “Siempre hay que respaldar datos con frecuencia”. A los usuarios les gusta dar
consejos, por lo que el analista debe tratar de capturarlos e incluirlos en la documentación de FOLKLORE.
La recopilación de formas artísticas es otra importante actividad de los folkloristas tradicionales, por lo que
el analista de sistemas también debe comprender su importancia. Los diagramas de flujo, los diagramas y las ta-
COSTUMBRES
Descripciones de la forma
en que los usuarios hacen
que funcione el sistema en
ese momento.
FOLKLORE
CUENTOS
Historias sobre la forma
en que los usuarios
pudieron hacer que
funcionara el sistema.
FORMAS ARTÍSTICAS
Diagramas, tablas y
diagramas de flujo.
DICHOS
“Haga esto y dará
resultado”.
FIGURA 16.5
Las costumbres, los relatos, los
dichos y las formas artísticas
utilizadas en el método de
documentación FOLKLORE se
aplican a los sistemas de
información.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 6 . 2
Escribir está bien
“Es tan fácil comprender. Yo digo que si todos usan pseudocó-
digo no habrá problemas, tú sabes, con eso de que las cosas no están
estandarizadas”, dice Al Gorithm, un nuevo programador que estará
trabajando en el equipo de análisis de sistemas que usted dirige. Al
está hablando en una reunión informal entre tres miembros del
equipo de análisis de sistemas, una fuerza de trabajo de MIS de seis
personas del departamento de publicidad y dos programadores; to-
dos se encuentran trabajando en el desarrollo de un sistema de in-
formación para el personal de publicidad.
Philip, un ejecutivo de cuentas de publicidad y miembro de la
fuerza de trabajo de MIS, mira sorprendido. “¿Cómo se llama este
método?”. Los dos programadores responden al mismo tiempo,
“Pseudocódigo”. Philip, sin verse impresionado, responde: “Eso no
me dice nada”.
Neeva Phail, uno de los analistas de sistemas, empieza a expli-
car: “Tal vez no importe realmente qué usemos, si...”
En ese momento interrumpe Flo Chart, otra analista de siste-
mas, para decir: “Odio el pseudocódigo”. A continuación mira con
esperanza a los programadores: “Estoy segura de que podemos
acordar una mejor técnica”.
David, un ejecutivo de publicidad con más años de experien-
cia, declara con apariencia ligeramente molesta: “Aprendí sobre los
diagramas de flujo desde los primeros analistas de sistemas que
tuvimos hace años. ¿Acaso ya no hacen eso ustedes? Creo que fun-
cionan mejor”.
Lo que en un principio era una reunión amistosa de repente
parece haber llegado a un punto muerto. Los participantes se miran
unos a otros con recelo. Usted, que como analista de sistemas ha
trabajado en muchos proyectos distintos con diferentes tipos de
personas, se da cuenta de que el grupo está a la espera de que usted
haga algunas sugerencias razonables.
Con base en lo que sabe sobre las diversas técnicas de docu-
mentación, ¿qué técnica(s) propondría a los miembros del grupo?
¿Cómo solucionará(n) la(s) técnica(s) que propuso algunas de las
cuestiones que han expresado? ¿Qué proceso utilizará para decidir
sobre las técnicas apropiadas? Elabore su respuesta en una página.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 525
blas que los usuarios dibujan algunas veces pueden ser mejores o más útiles que los diagramas de flujo dibujados
por el autor original del sistema. A menudo los analistas encontrarán dicho arte publicado en tableros de anun-
cios, o pueden pedir a los usuarios que limpien sus archivos y recuperen los diagramas que sean útiles.
Los colaboradores en el documento de FOLKLORE no tienen que documentar todo el sistema, sólo las par-
tes que conozcan. Al igual que con las comunidades de usuarios basadas en Web, el peligro de depender de FOL-
KLORE es que la información recopilada de los usuarios puede ser correcta, parcialmente correcta o incorrecta.
E X P E R I E N C I A D E H Y P E R C A S E ® 1 6 . 1
“ Éste es un lugar fascinante para trabajar. Estoy seguro que
usted está de acuerdo, ahora que ha tenido la oportunidad de obser-
varnos. Algunas veces creo que debería ser divertido ser un ex-
terno... ¿no se siente como un antropólogo que acaba de descubrir
una nueva cultura? Recuerdo cuando entré aquí por primera vez.
Todo era tan nuevo, tan extraño. Incluso hasta el lenguaje era dis-
tinto. No era un ‘consumidor’, era un ‘cliente’. No teníamos ‘depar-
tamentos’ sino ‘unidades’. No era una cafetería para empleados, era
el ‘comedor’. Esto se aplica también a la forma en que trabajamos.
Todos tenemos distintas formas de abordar las cosas. Creo que es-
toy entendiendo las expectativas de Snowden, pero de vez en cuando
cometo un error también. Por ejemplo, si puedo entregarle el trabajo
en línea, él lo preferiría a un informe impreso. ¡Ésa es la razón por
la que tengo dos computadoras en mi escritorio, también! Siempre
veo que usted está haciendo muchas anotaciones... creo que tiene
sentido. Se supone que debe documentar lo que nosotros hacemos
con nuestros sistemas e información, así como lo que está haciendo
su equipo, ¿verdad?”.
Preguntas de HYPERCASE
1. Use el método FOLKLORE para completar la
documentación del sistema GEMS de la Unidad de sistemas
de información administrativa (Management Information
Systems Unit). Asegúrese de incluir las costumbres, relatos,
dichos y formas artísticas.
2. Sugiera en dos párrafos una metodología basada en PC para
capturar los elementos de FOLKLORE, de manera que no sea
necesario usar un registro basado en papel. Asegúrese de que
la solución que sugiera pueda alojar tanto gráficos como texto.
3. Diseñe pantallas de entrada y salida para FOLKLORE que
faciliten la introducción de datos y provean indicadores para
recordar de inmediato los elementos de FOLKLORE.
FIGURA 16.HC1
En HyperCase puede usar FOLKLORE para documentar formas artísticas creadas o
recolectadas por los usuarios para hacer uso de sus sistemas.www.xlibros.com

526 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
PRUEBA
Prueba completa de
sistemas con
datos reales
USUARIOS
ANALISTAS
Prueba de vínculos
con datos de prueba
Prueba de los programas con
datos de prueba
Prueba completa
de sistemas con
datos de prueba
OPERADORES
PROGRAMADORES
FIGURA 16.6
Los programadores, analistas,
operadores y usuarios desempeñan
distintos roles en el proceso de
prueba del software y los sistemas.
Elección de una técnica de diseño y documentación
Las técnicas que vimos en este capítulo son extremadamente valiosas como herramientas de diseño, ayudas de
memoria, herramientas de productividad y medio para reducir las dependencias en los miembros clave del perso-
nal. Sin embargo, el analista de sistemas se enfrenta a una difícil decisión en cuanto al método que debe adoptar.
A continuación le mostramos un conjunto de lineamientos para ayudar al analista a utilizar la técnica apropiada:
Seleccione una técnica que:
1. Sea compatible con la documentación existente.
2. Sea comprendida por los demás en la organización.
3. Le permita regresar a trabajar en el sistema después de haber estado alejado durante un periodo de tiempo.
4. Sea adecuada para el tamaño del sistema en el que está trabajando.
5. Permita una metodología de diseño estructurado, si eso se considera más importante que otros factores.
6. Permita modificarla con facilidad.
PRUEBA, MANTENIMIENTO Y AUDITORÍA
Una vez que el analista ha diseñado y codificado el sistema, la prueba, mantenimiento y auditoría de éste son las
consideraciones primordiales.
El proceso de prueba
Todos los programas de aplicaciones recién escritos o modificados del sistema (así como los nuevos manuales de
procedimientos, el nuevo hardware y todas las interfaces del sistema) se deben probar de manera exhaustiva. No
basta con el método de prueba y error al azar. La prueba se realiza durante el desarrollo de sistemas y no sólo al
final. Su propósito es sacar a la luz los problemas desconocidos hasta ese momento, no demostrar la perfección
de los programas, manuales o equipo.
Aunque el proceso de prueba es tedioso, es una serie esencial de pasos que ayudan a asegurar la calidad del
sistema eventual. Es mucho menos perjudicial evaluar con anticipación a tener un sistema probado en forma in-
correcta que falle después de su instalación. Las pruebas se realizan en los subsistemas o módulos del programa
a medida que avanza su desarrollo. El proceso de prueba se lleva a cabo en muchos niveles, a diversos intervalos.
Antes de poner el sistema en producción hay que realizar una verificación de escritorio de todos los programas,
comprobarlos con datos de prueba y comprobar que los módulos funcionen en conjunto como se había pla-
neado.
También hay que probar el sistema como un todo funcional. Aquí se incluye la prueba de las interfaces entre
los subsistemas, la exactitud de la salida, además de la utilidad y comprensibilidad de la documentación y salida
del sistema. Los programadores, analistas, operadores y usuarios desempeñan distintos roles en los diversos as-
pectos del proceso de prueba, como se muestra en la figura 16.6. Por lo general la prueba del hardware se pro-
porciona como un servicio por parte de los distribuidores de equipo, quienes realizan sus propias pruebas en el
equipo cuando se entrega en el sitio.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 527
PRUEBA DE PROGRAMAS CON DATOS DE PRUEBA Gran parte de la responsabilidad de la prueba de los
programas recae en el (los) autor(es) original(es) de cada programa. El analista de sistemas actúa como
consejero y coordinador para la prueba de los programas; su objetivo es asegurar que los programadores
implementen las técnicas de prueba correctas, pero es probable que no lleve a cabo personalmente este nivel de
comprobación.
En esta etapa los programadores primero deben realizar una verificación de escritorio de sus programas para
comprobar la forma en que funcionará el sistema. En este tipo de comprobación el programador sigue cada paso
del programa en papel para verificar que la rutina funcione según lo escrito.
A continuación, los programadores deben crear datos de prueba tanto válidos como inválidos. Luego se eje-
cutan los programas con estos datos para ver si las rutinas básicas funcionan y detectar errores. Si la salida de los
módulos principales es satisfactoria, puede agregar más datos de prueba para verificar otros módulos. Los datos
de prueba creados deben probar los valores mínimos y máximos posibles, así como todas las posibles variacio-
nes en formato y códigos. La salida de archivos de los datos de prueba se debe verificar con cuidado. Nunca
debemos asumir que los datos que contiene un archivo son correctos sólo porque se creó y se pudo acceder a su
contenido.
Durante este proceso el analista de sistemas verifica la salida en busca de errores y aconseja al programador
en caso de requerir alguna corrección. Por lo general el analista no recomienda ni crea datos de prueba para pro-
bar los programas, pero podría señalar al programador las omisiones de los tipos de datos que se deban agregar
en pruebas posteriores.
PRUEBA DE VÍNCULOS CON DATOS DE PRUEBA Cuando los programas pasan la verificación de escritorio y la
comprobación con datos de prueba, deben pasar por la prueba de vínculos, a la cual también se le conoce como
prueba de cadena. La prueba de vínculos verifica que los programas interdependientes trabajen juntos realmente
como se planeó.
El analista crea datos especiales de prueba que abarcan varias situaciones de procesamiento para la prueba
de vínculos. Primero se procesan los datos de prueba comunes para ver si el sistema puede manejar las transac-
ciones normales, las que representan la mayor parte de su carga. Si el sistema funciona con las transacciones
normales se agregan variaciones, incluyendo los datos inválidos utilizados para asegurar que el sistema pueda
detectar errores en forma apropiada.
PRUEBA DE SISTEMAS COMPLETOS CON DATOS DE PRUEBA Al concluir de manera satisfactoria las pruebas de
vínculos, se debe probar el sistema como una entidad completa. En esta etapa, los operadores y usuarios finales
se involucran de manera activa en la prueba. Aquí se utilizan los datos de prueba creados por el equipo de análisis
de sistemas con el propósito específico de probar los objetivos del sistema.
Como es de esperarse, hay varios factores a considerar a la hora de probar sistemas con datos de prueba:
1. Examinar si los operadores tienen la documentación adecuada en los manuales de procedimiento (impresos
o en línea) para lograr una operación correcta y eficiente.
2. Verificar si los manuales de procedimientos son lo bastante claros para comunicar la forma en que se deben
preparar los datos para la entrada.
3. Averiguar si los flujos de trabajo requeridos por el sistema nuevo o modificado realmente “fluyen”.
4. Determinar si la salida es correcta y si los usuarios comprenden que esta salida es casi idéntica a la
apariencia que tendrá en su forma final.
Recuerde programar el tiempo adecuado para la prueba del sistema. Por desgracia este paso se pasa por alto con
frecuencia si la instalación del sistema está requiriendo más tiempo del planeado.
La prueba de sistemas incluye la reafirmación de los estándares de calidad establecidos para el desempeño
del sistema al crear sus especificaciones iniciales. Todos los involucrados deben estar una vez más de acuerdo
en cómo determinar si el sistema hace lo que se supone que debe hacer. Este paso debe incluir medidas de error,
conveniencia, facilidad de uso, orden apropiado de las transacciones, tiempo inactivo aceptable y manuales de
procedimientos comprensibles.
PRUEBA DE SISTEMAS COMPLETA CON DATOS REALES Cuando las pruebas de sistemas con datos de prueba
resulten satisfactorias, es conveniente probar el nuevo sistema con varias corridas de datos reales, es decir,
usando datos satisfactoriamente procesados por el sistema anterior. Este paso permite una comparación precisa
de la salida del nuevo sistema con lo que sabemos que es una salida procesada en forma correcta, además de
que es una buena idea para probar cómo se manejarán los datos reales. Sin duda, este paso no es posible al crear
salidas completamente nuevas (por ejemplo, la salida de una transacción de comercio electrónico de un nuevo
sitio Web corporativo). Al igual que con los datos de prueba, se utilizan sólo pequeñas cantidades de datos reales
en este tipo de prueba del sistema.www.xlibros.com

528 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
O P O R T U N I D A D D E C O N S U L T O R Í A 1 6 . 3
Estudiando de manera intensiva para su prueba de sistemas
“ Estamos cortos de tiempo. Sólo mira esta proyección”, dice
Lou Scuntroll, el miembro más reciente del equipo de análisis de
sistemas que usted dirige, mientras le muestra el diagrama PERT que
el equipo ha estado utilizando para proyectar cuándo estaría listo y
funcionando el nuevo sistema. “No hay posibilidad de cumplir con
la fecha final de julio para la prueba con datos reales. Estamos atra-
sados tres semanas debido a la tardanza en el envío del equipo”.
Usted, que como analista de sistemas ha visto cómo vienen y
van las fechas de entrega en otros proyectos, trata de permanecer
tranquilo y de evaluar la situación con cuidado antes de hablar. Con
lentitud cuestiona a Lou sobre la posibilidad de retrasar la prueba.
Lou le responde: “Si tratamos de aplazar la prueba hasta las
primeras semanas de agosto, hay dos personas clave de contabilidad
que van a estar de vacaciones”. Lou se ve visiblemente molesto ante
la posibilidad de no cumplir con la fecha de entrega.
Stan Dards, otro miembro reciente de su equipo de análisis de
sistemas, entra a la oficina de Lou. “Ustedes dos tienen una aparien-
cia terrible. Las cosas van bien, ¿o no? No me van a reasignar para
programar una aplicación de nómina, ¿o sí?”
Lou voltea hacia arriba, y es obvio que no aprecia el sentido de
humor de Stan ni lo que le preocupa en ese momento. “Qué bueno
que entraste. Tenemos que tomar algunas decisiones importantes
sobre la calendarización”. Lou sostiene el diagrama PERT para que
Stan lo inspeccione. “Observa la fecha de prueba en julio. Como
verás, no hay forma de lograrlo. ¿Alguna brillante idea?”.
Stan contempla el diagrama por un momento y después dice:
“Algo se tiene que ir. Veamos aquí... tal vez pasar la prueba del
módulo de contabilidad a...”.
Lou lo interrumpe y dice rotundamente: “No, ya pensé en ello
pero Stanford y Binet de contabilidad van a salir de la ciudad en
agosto. Tal vez podamos omitir esa parte de la prueba. Han coope-
rado mucho. No creo que se opongan a que lo ‘demos por hecho’ y
realicemos la prueba cuando entremos en producción”.
“Creo que es una buena idea, Lou”, asiente Stan, tratando de
compensar lo de sus bromas anteriores. “No hemos tenido ningún
problema real con eso y los programadores están muy confiados. De
esa forma podríamos permanecer dentro del itinerario con todo lo
demás. Voto por no probar la porción correspondiente a contabili-
dad, sino simplemente hacer como si todo saliera bien”.
Como el miembro más antiguo del equipo presente, ¿qué
puede hacer para convencer a Lou y Stan sobre la importancia de
probar el módulo de contabilidad con datos reales? ¿Qué pueden
hacer los analistas de sistemas para planificar su tiempo y permitir
el tiempo adecuado para probar con datos de prueba y datos reales?
¿Cuáles son algunos de los posibles problemas a los que se pueden
enfrentar los miembros del equipo si no prueban el sistema por
completo con datos reales, antes de poner el sistema en producción?
¿Hay en realidad pasos en el proceso de análisis y diseño de siste-
mas que se puedan colapsar para que un proyecto retrasado vuelva
a estar a tiempo? Responda a estas preguntas en dos páginas.
Aunque hemos considerado con mucho detenimiento la interacción entre usuario y sistema (vea el capítulo
14), nunca podremos predecir por completo todo el rango de diferencias que ésta asume. No es suficiente en-
trevistar a los usuarios sobre la forma en que están interactuando con el sistema; debemos observarlos personal-
mente.
Los elementos a observar son la facilidad de aprender a usar el sistema y la reacción de los usuarios a la
retroalimentación del sistema, incluyendo lo que ocurre al recibir un mensaje de error y lo que ocurre cuando se
informa al usuario que el sistema está ejecutando sus comandos. Hay que estar especialmente atentos a la forma
en que los usuarios reaccionan al tiempo de respuesta del sistema y al lenguaje de las respuestas. También hay
que escuchar lo que dicen los usuarios sobre el sistema a medida que lo van descubriendo. Hay que resolver
cualquier problema real antes de poner el sistema en producción, no sólo encubrirlos como ajustes al sistema que
los usuarios y operadores deberían realizar por su cuenta.
Al igual que el software de computadora, también hay que probar los manuales de procedimientos. Aunque
el personal de soporte puede revisar los manuales, y el equipo de análisis de sistemas puede verificar su precisión
técnica, la única forma real de probarlos es a través de los usuarios y operadores, de preferencia cuando se reali-
zan pruebas completas en el sistema con datos reales. Considere las sugerencias de los usuarios e incorpórelas en
las versiones finales de las páginas Web, los manuales impresos y el resto de la documentación.
Prácticas de mantenimiento
Su objetivo como analista de sistemas debe ser instalar o modificar sistemas que tengan una vida útil razona-
ble. Lo ideal es crear un sistema cuyo diseño sea integral y con una suficiente visión a futuro suficiente para
atender las necesidades actuales y proyectadas de los usuarios durante los años por venir. Recurra a su expe-
riencia para anticipar esas necesidades y después agregar tanto flexibilidad como capacidad de adaptación al
sistema. Entre mejor sea el diseño del sistema, más fácil será mantenerlo y menos dinero tendrá que invertir la
empresa en ello.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 529
Reducir los costos de mantenimiento es primordial, ya que el mero mantenimiento del software puede devo-
rar hasta el 50 por ciento del presupuesto total de procesamiento de datos de una empresa. Los costos excesivos
de mantenimiento son responsabilidad del diseñador del sistema, ya que cerca del 70 por ciento de los errores de
software se atribuyen a un diseño de software inapropiado. Desde la perspectiva de sistemas, tiene sentido el he-
cho de que detectar y corregir los errores de diseño de software lo antes posible sea menos costoso que dejar que
pasen desapercibidos hasta que sea necesario el mantenimiento.
La mayor parte de las veces el mantenimiento se realiza para mejorar el software existente y no para respon-
der a una crisis o falla del sistema. El mantenimiento también se realiza para actualizar software en respuesta a
los cambios en la organización. Este trabajo no es tan sustancial como mejorar el software, pero hay que hacerlo.
El mantenimiento de emergencia y adaptativo representa menos de la mitad de todo el mantenimiento del sis-
tema.
Parte del trabajo del analista de sistemas es asegurar que se implementen los canales y procedimientos
adecuados para permitir la retroalimentación sobre las necesidades de mantenimiento y las acciones para sa-
tisfacerlas. Para los usuarios debe ser fácil comunicar los problemas y las sugerencias a los encargados de dar
mantenimiento al sistema. Las soluciones son proveer a los usuarios el acceso vía correo electrónico al soporte
técnico, así como permitirles descargar actualizaciones de productos o parches a través de la Web.
Auditoría
La auditoría es otra forma de asegurar la calidad de la información que contiene el sistema. En términos genera-
les, la auditoría se refiere al proceso de hacer que un experto que no esté involucrado en el proceso de establecer
o usar un sistema examine la información para evaluar su confiabilidad. Sin importar que la información resulte
confiable o no, el hallazgo sobre su confiabilidad se comunica a los demás con el fin de que actúen en conse-
cuencia.
Para los sistemas de información, en general hay dos tipos de auditores: internos y externos. El hecho de
determinar si ambos son necesarios para el sistema que usted diseñe dependerá del tipo de sistema. Los auditores
internos trabajan para la misma organización que posee el sistema de información, mientras que los auditores ex-
ternos (también llamados independientes) se contratan del exterior.
Los auditores externos se utilizan cuando el sistema de información procesa datos que influyen en los esta-
dos financieros de la empresa; los externos realizan una auditoría sobre el sistema para asegurar la imparcia-
lidad de los estados financieros que se producen. También se pueden usar cuando ocurre algo fuera de lo normal
en el que hay empleados de la empresa involucrados, como una sospecha de fraude por computadora o malver-
sación de fondos.
Los auditores internos estudian los controles que se utilizan en el sistema de información para asegurarse de
que sean adecuados y que estén realizando la función esperada. También evalúan la conveniencia de los controles
de seguridad. Aunque trabajan para la misma organización, los auditores internos no se reportan con la persona
responsable del sistema al que están auditando. Con frecuencia, el trabajo de los auditores internos es más pro-
fundo que el de los auditores externos.
IMPLEMENTACIÓN DE SISTEMAS DISTRIBUIDOS
Si la confiabilidad de una red de telecomunicaciones es alta, es posible tener sistemas distribuidos para las em-
presas; podemos concebir este arreglo como una aplicación de las telecomunicaciones. El concepto de sistemas
distribuidos se utiliza de muchas formas. Aquí lo consideraremos en un sentido general para incluir las estacio-
nes de trabajo que se pueden comunicar entre sí y con los procesadores de datos, así como las distintas configu-
raciones arquitectónicas jerárquicas de los procesadores de datos que se comunican entre sí y que tienen distintas
capacidades de almacenamiento de datos.
En este modelo, las funciones de procesamiento se delegan a los clientes (usuarios) o a los servidores, de-
pendiendo de las máquinas que sean más adecuadas para ejecutar el trabajo. En este tipo de arquitectura, la parte
de una aplicación de red correspondiente al cliente se ejecutará en el sistema cliente y la parte de la aplicación
correspondiente al servidor se ejecutará en el servidor de archivos. Con un modelo cliente-servidor los usuarios
interactúan con partes limitadas de la aplicación, incluyendo la interfaz de usuario, la entrada de datos, las con-
sultas en la base de datos y la generación de informes. El servidor se encarga de las funciones de controlar el
acceso de los usuarios a las bases de datos centralizadas, recuperar o procesar los datos y demás funciones rela-
cionadas (como administrar los dispositivos periféricos).
Tecnología cliente-servidor
El modelo cliente-servidor, la computación cliente-servidor, la tecnología cliente-servidor y la arquitectura clien-
te-servidor se refieren a un modelo de diseño que podemos considerar como aplicaciones que se ejecutan en unawww.xlibros.com

530 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Servidor Web
(maneja el intercambio de
información basada en Web)
Computadoras cliente
(el medio de entrada y
visualización de información)
Servidor de aplicaciones
(procesa datos que entran y
salen de las computadoras
cliente y del servidor de
bases de datos)
Servidor de bases de datos
(almacena y
recupera datos)
FIGURA 16.7
Una configuración cliente-servidor
de tres niveles.
red. En términos muy básicos, podemos imaginar que el cliente hace (y el servidor ejecuta, o cumple de cierta
forma con) la solicitud. Eso se consideraría una arquitectura cliente-servidor de dos niveles.
Hay una configuración más compleja en la que se involucran tres conjuntos de computadoras para realizar
los procesos de recuperación, procesamiento, almacenamiento y recepción de los datos. La figura 16.7 muestra
un modelo cliente-servidor de tres niveles. En esta figura, las computadoras cliente acceden a tres niveles de ser-
vidores: los servidores Web, que manejan el intercambio de información basado en Web; los servidores de apli-
caciones, que procesan datos que entran y salen de las computadoras cliente y el servidor de bases de datos; y el
servidor de bases de datos, que almacena y recibe los datos. Las computadoras en la red están programadas para
realizar su trabajo con eficiencia al dividir las tareas de procesamiento entre los clientes y servidores.
Piense en el modelo cliente/servidor como en un sistema que coloca a los usuarios como el centro del tra-
bajo, con su interacción con datos como concepto clave. Aunque hay dos elementos funcionando —el cliente y el
servidor— el objetivo del modelo cliente-servidor es que los usuarios lo vean como un sistema. De hecho, se es-
pera que los usuarios no adviertan cómo desempeña la red cliente-servidor su procesamiento distribuido, debido
a que debe tener la apariencia de un sistema unificado. En una red de igual a igual, las PC pueden actuar como el
servidor o el cliente, dependiendo de los requerimientos de la aplicación.
CLIENTES COMO PARTE DEL MODELO CLIENTE-SERVIDOR Al ver el término cliente, podría verse tentado a pensar
en personas o usuarios; por ejemplo, hablamos de “clientes de nuestra práctica de consultoría”. Sin embargo, en
el modelo cliente-servidor el término cliente no se refiere a las personas, sino a máquinas conectadas en red que
son los puntos típicos de entrada al sistema cliente-servidor que utilizan los humanos. Por lo tanto, los clientes
podrían ser computadoras de escritorio conectadas en red, una estación de trabajo, computadoras portátiles o
cualquier otra forma en que el usuario pueda entrar al sistema.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 531
Al usar una interfaz gráfica de usuario (GUI), los individuos por lo general interactúan en forma directa
sólo con la parte del cliente. Las estaciones de trabajo del cliente usan programas más pequeños que residen en
el cliente para hacer el procesamiento en primer plano (contrario al procesamiento en segundo plano, que men-
cionaremos más adelante), incluyendo la comunicación con el usuario. Si una aplicación se denomina aplicación
basada en el cliente, la aplicación reside en una computadora cliente y otros usuarios en la red no pueden acceder
a ella.
ANÁLISIS DE LAS VENTAJAS Y DESVENTAJAS DEL MODELO CLIENTE-SERVIDOR Las primeras empresas en adoptar
el modelo cliente-servidor descubrieron que no siempre es la mejor solución a los problemas informáticos de
la organización. Con frecuencia, se pide al diseñador de sistemas que avale un modelo cliente-servidor que ya
está en funcionamiento. Así como con cualquier otra propuesta de cómputo corporativa en cuya creación usted
no haya tenido una parte activa, debe revisar el plan cuidadosamente. ¿Apoyará la cultura de la organización un
modelo cliente-servidor? ¿Qué cambios es necesario hacer en la cultura informal y en los procedimientos de
trabajo formales para que un modelo cliente-servidor se pueda usar con todo su potencial? ¿Cuál debe ser su rol
como analista de sistemas en esta situación?
Aunque uno de los beneficios mencionados del modelo cliente-servidor son costos más bajos de procesa-
miento, hay muy pocos datos reales disponibles para demostrarlo (incluso cuando hay alguna evidencia anecdó-
tica para apoyar esta aseveración). Hay costos de cambio y costos iniciales muy bien documentados asociados
con una migración hacia una arquitectura cliente-servidor. Las aplicaciones para el modelo cliente-servidor se
deben escribir como dos componentes de software, cada uno de los cuales se ejecuta en una máquina separada,
pero que deben aparecer como si operaran como una sola aplicación. Sin embargo, usar el modelo cliente-servi-
dor permite usar mayor poder de cómputo y brinda una mejor oportunidad de personalizar las aplicaciones, en
comparación con las otras opciones.
Aunque las redes se pueden caracterizar por su forma o topología, también se clasifican por su alcance
geográfico y los tipos de servicios que ofrecen. Los tipos estándares de redes incluyen una red de área amplia
(WAN) y una red de área local (LAN). Las LAN son estándares para vincular computadoras locales o terminales
en un departamento, edificio o varios edificios de una organización. Las WAN pueden servir a los usuarios a tra-
vés de varios kilómetros o de continentes enteros.
Ahora, conectar una red también es técnica, económica y operacionalmente factible para las oficinas pe-
queñas y proporciona una solución que los analistas deben considerar para los negocios pequeños. Uno de los
aspectos costosos a la hora de implementar una LAN es que cada vez que se mueve hay que volver a tender el
cableado. Algunas organizaciones están haciendo frente a este problema mediante la aplicación de una red de
área local inalámbrica de alta velocidad (WLAN). Dicho en forma más específica, a estas redes inalámbricas se
les conoce como Wi-Fi.
Computación en nube
En la actualidad, el tipo de computación con un crecimiento más rápido es la computación en nube. Este tipo de
computación se describe como una metáfora para Internet, ya que a menudo Internet se dibuja como una nube en
los diagramas de red. Al utilizar la computación en nube, las organizaciones y los usuarios individuales pueden
usar servicios Web, servicios de bases de datos y servicios de aplicaciones a través de Internet, sin tener que
invertir en hardware corporativo o personal, software o herramientas de software. La figura 16.8 describe los in-
tercambios entre computadoras cliente y los servicios en la nube. Las empresas utilizan navegadores Web como
Microsoft Internet Explorer o Mozilla Firefox para acceder a estas aplicaciones. Como puede ver, los servidores
almacenan software y datos para las empresas.
Muchas empresas de hardware, software y consultoría grandes y bien establecidas como Cisco, Dell, IBM,
HP, Microsoft, SAP y otras están llevando a cabo esfuerzos masivos de computación en nube, a menudo con lo
que se denomina “recursos virtualizados”. Lo distinto de estas metodologías es su habilidad de crecer y adaptarse
a las necesidades cambiantes de las empresas. Es decir, son escalables para adaptarse a la demanda creciente
(o cambiante) por parte de los usuarios. El modelo de “software como un servicio”, también conocido como
SaaS, se incluye en el concepto de la computación en nube.
Por su parte, los usuarios no necesitan comprender, controlar o ser expertos en la infraestructura de tecno-
logía que constituye la compleja infraestructura de nube que les permite realizar su trabajo. Con frecuencia las
organizaciones no necesitan mantener personal de TI para dimensionar hacia arriba o hacia abajo, incluso cuando
el contrato o presupuesto de una compañía cambie en forma ascendente o descendente debido al impacto redu-
cido de estos cambios.
Es común que las organizaciones que utilizan la computación en nube no encuentren necesario realizar gas-
tos iniciales de capital en infraestructura de TI, por lo que las empresas más pequeñas con presupuestos menores
y menos predecibles pueden avanzar en el procesamiento con más rapidez. Esto también permite a las grandes
corporaciones invertir en proyectos estratégicos en vez de hacerlo en infraestructura de TI.www.xlibros.com

532 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Servicios Web Servicios de
aplicaciones
Servicios de bases
de datos
Computadoras cliente
FIGURA 16.8
La computación en nube ofrece
muchos servicios.
Compartir recursos de TI por medio de la computación en nube significa que una gran colección de usuarios
corporativos comparten servicios Web, pero también tienen que compartir el costo de éstos; además descubren
que aumenta la capacidad de carga máxima y que se puede maximizar la eficiencia y el uso de los sistemas.
Las empresas también esperan mejorar su habilidad de desempeñar el proceso de recuperación de desastres
mediante el uso de la computación en nube, ya que provee muchos sitios redundantes. Aunque la computación en
nube no es inmune a los cortes de energía, puede dividir el riesgo entre varios servidores.
Las organizaciones tratan de mejorar la seguridad a través de la computación en nube y mediante el uso de
servicios que se venden con un énfasis especial en la seguridad. Sin embargo, existe la preocupación de que la
centralización de este tipo pueda también significar una pérdida del control sobre los datos de misión crítica. Los
usuarios se podrían beneficiar de la movilidad al no estar supeditados a una sola instalación de computadora o
una sola interfaz. Los navegadores Web y los servicios basados en Web disponibles a través de la computación en
nube liberan a los usuarios para acceder a las aplicaciones en cualquier parte y a cualquier hora, sin preocuparse
por la ubicación o el dispositivo que vayan a utilizar.
Muchas empresas grandes de software (algunas de las cuales se denominan “jugadores puros” o “pure
players”, ya que nunca han existido como empresas con presencia física) ofrecen aplicaciones que utilizan la
computación en nube, en donde los usuarios pueden utilizar su navegador Web para acceder a las aplicaciones.
Algunos ejemplos son Google Apps (para hojas de cálculo y calendarios), Amazon Web Services, Akami y el
software CRM de Salesforce.com que ahora también está disponible en el iPhone. Estos proveedores de software
afirman que están tratando de reducir el costo para el usuario, así como de proporcionar mayor flexibilidad.
Algunos observadores tienen la creencia de que migrar a la computación en nube es una forma de que las
empresas más grandes y antiguas se solidifiquen y retengan sus negocios esenciales al incorporar SaaS (softwarewww.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 533
como un servicio), SOA (Arquitectura orientada a servicios), virtualización, código fuente abierto y muchas otras
tendencias de la última década en sus ofrecimientos de software, herramientas de software, servicios y poder de
cómputo vía Internet. Pero si el costo de la infraestructura cayera drásticamente (como lo ha hecho según la his-
toria), el impulso hacia la computación en nube se podría invertir. Si eso ocurriera, las organizaciones podrían to-
mar decisiones distintas e invertir una vez más en su propia infraestructura. Además, muchos de los servicios en
línea que conforman la computación en nube se pagan por medio de los ingresos provenientes de la publicidad.
En una economía vacilante se reducirían los ingresos por publicidad y los patrocinios de la computación en nube
podrían disminuir también.
Modelado de red
Debido a que la conexión a una red se ha vuelto muy importante, el diseñador de sistemas necesita tomar en
cuenta al diseño de la red. Ya sea que un diseñador de sistemas tenga que decidir sobre las configuraciones de las
redes —o si se preocupa por el hardware tal como enrutadores y puentes que deben estar en el lugar cuando se
conocen las redes—, siempre debe tomar en cuenta el diseño lógico de las redes.
Un analista debe adoptar un conjunto de símbolos tal como los de la figura 16.9 para modelar la red. Es útil
tener diferentes símbolos para distinguir entre concentradores, redes externas y estaciones de trabajo. También
es útil adoptar una convención para ilustrar múltiples redes y estaciones de trabajo. El primer paso es dibujar un
diagrama de descomposición de red que proporcione una apreciación global del sistema. Después, dibujar
un diagrama de conectividad de concentrador. Finalmente, dividir el diagrama de conectividad de concentrador
para mostrar las diversas estaciones de trabajo y cómo se conectan.
CÓMO DIBUJAR UN DIAGRAMA DE DESCOMPOSICIÓN DE RED Podemos ilustrar el dibujo de un modelo de
descomposición de red al referirnos una vez más al ejemplo de World’s Trend Catalog Division de los capítulos
anteriores. Empiece dibujando un círculo en la parte superior y denominándolo “Red de World’s Trend”.
Ahora dibuje varios círculos en el nivel inferior, como se muestra en la figura 16.10. Estos círculos representan
los concentradores para la división de marketing y para cada uno de los tres centros de toma de pedidos y
distribución (división estadounidense, división canadiense y división mexicana).
Podemos extender este dibujo al dibujar otro nivel. Esta vez, podemos agregar las estaciones de trabajo.
Por ejemplo, la división de marketing tiene dos estaciones de trabajo conectadas, mientras que la división esta-
dounidense tiene 33 estaciones de trabajo en su LAN (administración, almacén, gerente de entrada de pedido y
30 empleados de entrada de pedido). Esta red se simplifica con el propósito de proporcionar un ejemplo fácil de
entender.
Concentrador o red de área local
Red externa
Varias redes externas con funciones similares
Estación de trabajo
Varias estaciones de trabajo con funciones similares
FIGURA 16.9
Use símbolos especiales al dibujar
diagramas de descomposición
de red y de conectividad de
concentrador.www.xlibros.com

534 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Red de
World’s
Trend
División de
marketing
División
estado-
unidense
División
canadiense
División
mexicana
Adminis-
tración
Almacén
estado-
unidense
Almacén
mexicano
Gerente de
entrada de
pedido
Empleados de
entrada de
pedido
(4)
Gerente de
entrada de
pedido
Empleados de
entrada de
pedido
(8)
Gerente de
entrada de
pedido
Empleados de
entrada de
pedido
(30)
Gerente de
publicidad
Publicaciones
de catálogos
Proveedores
(21)
Almacén
canadiense
FIGURA 16.10
Un diagrama de descomposición
de red para World’s Trend.
CREACIÓN DE UN DIAGRAMA DE CONECTIVIDAD DE CONCENTRADOR El diagrama de conectividad de
concentrador es útil para mostrar cómo se conectan los concentradores principales. En World’s Trend (véase la
figura 16.11) hay cuatro concentradores principales conectados entre sí. Además, hay concentradores externos
(proveedores) que necesitan ser notificados cuando el nivel de inventario baja a un cierto punto, etc. Cada una de
las tres divisiones de país se conecta a los 21 proveedores; sin embargo, la división de marketing no se necesita
conectar a los proveedores.
División de
marketing
División
mexicana
División
canadiense
División
estado-
unidense
50 millas
625 millas
1–3,500 millas
10–3,500 millas
2,750 millas
50–3,500 millas Proveedores
(21)
FIGURA 16.11
Un diagrama de conectividad de
concentrador para World’s Trend.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 535
Para producir un diagrama de conectividad de concentradores eficaz, empiece por dibujar todos los concen-
tradores. Después experimente (quizás haciendo primero un bosquejo en una hoja de papel) para ver qué víncu-
los son necesarios. Una vez hecho esto, puede volver a dibujar el diagrama para que sea atractivo e informe bien
a los usuarios.
EXPANSIÓN DEL DIAGRAMA DE CONECTIVIDAD DE CONCENTRADORES EN UN DIAGRAMA DE CONECTIVIDAD DE
ESTACIONES DE TRABAJO El propósito del modelado de redes es mostrar la conectividad de las estaciones de
trabajo con un cierto nivel de detalle. Para ello hay que expandir el diagrama de conectividad de concentradores.
La figura 16.12 muestra cada una de las 33 estaciones de trabajo para la división estadounidense y cómo se
deben conectar.
Dibuje los diagramas para este nivel examinando el tercer nivel del diagrama de descomposición de red.
Agrupe artículos tales como Gerente de entrada de pedido y Empleados de entrada de pedido, debido a que ya
reconoce que se deben conectar. Use un símbolo especial para mostrar múltiples estaciones de trabajo e indique
en paréntesis el número de estaciones de trabajo similares. En nuestro ejemplo, hay 30 empleados de entrada de
pedido.
En el perímetro del diagrama, coloque estaciones de trabajo que se deben conectar a otros concentrado-
res. De esta forma, será más fácil representar estas conexiones usando flechas. Dibuje las conexiones exter-
nas en un color diferente o use flechas más gruesas. Por lo general, las conexiones externas están a grandes
distancias. Por ejemplo, la administración se conecta a la división de marketing, la cual está a 50 millas,
y también a las divisiones canadiense y mexicana. El almacén necesita comunicarse directamente con los
almacenes canadiense y mexicano en caso de que sea posible obtener la mercancía de otro almacén. El ge-
rente de entrada de pedido y los empleados de entrada de pedido no tienen que estar conectados con nadie
fuera de su LAN.
VENTAJAS DE LOS SISTEMAS DISTRIBUIDOS Los sistemas distribuidos permiten el almacenamiento de datos en
lugares donde no estorben a las transacciones de tiempo real en línea. Por ejemplo, el tiempo de respuesta en las
consultas se podría mejorar si no todos los registros necesitan ser investigados antes de que se dé una respuesta.
Además, los usuarios no necesitan los datos todo el tiempo, de modo que se pueden almacenar en medios menos
caros en un sitio diferente y se pueden acceder sólo cuando sea necesario.
El uso de sistemas distribuidos también puede bajar los costos de equipo, debido a que no todas las partes
del sistema necesitan desempeñar todas las funciones. Se hace posible compartir algunas habilidades tales como
procesamiento y almacenamiento.
300 pies
250 pies
200–250 pies
50–100 pies500 pies
A la división canadiense
575 millas
50–3,500 millas
A los proveedores
50 millas
A la división de
marketing
A la división mexicana
2,800 millas
A la división canadiense
575 millas
A la división mexicana
2,800 millas
Gerente de
entrada de
pedido
Empleados
de entrada
de pedido
(30)
Adminis-
tración
Almacén
FIGURA 16.12
Un diagrama de conectividad de
estaciones de trabajo para World’s
Trend.www.xlibros.com

536 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
Los sistemas distribuidos también pueden ayudar a bajar los costos al permitir la flexibilidad en la elección
del fabricante, debido a que el enfoque total de redes se centra en la comunicación entre nodos y los fabricantes
hacen componentes compatibles. Esta compatibilidad permite al usuario tomar decisiones de compra con base
en el precio así como en la funcionalidad. Además, al principio, los sistemas distribuidos pueden ser menos
costosos que los sistemas grandes porque es posible diseñar para la expansión sin realmente tener que comprar
el hardware en el momento que el sistema se implementa. El desarrollo de intranets corporativas es una forma
anticipada de conectar a una red a los miembros de la organización, una forma que también puede servir como
medio para reducir los aspectos problemáticos de Internet (tal como navegar sin objeto por Internet en horas de
oficina o posibles fallas de seguridad causadas por la falta de firewall) y al mismo tiempo como apoyo al trabajo
de grupo con aplicaciones útiles. Las extranets formadas con proveedores y otros socios importantes también son
excelentes formas de demostrar que un negocio está orientado hacia el exterior y es accesible. En la figura 16.13
se mencionan ventajas de los sistemas distribuidos.
DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS Los sistemas distribuidos presentan algunos problemas únicos
que los sistemas de cómputo centralizados no poseen. El analista necesita pesar estos problemas contra las
ventajas presentadas y plantearlos también con la empresa interesada.
El primer problema es la confiabilidad de la red. Para hacer de una red un recurso en lugar de una carga,
debe ser posible transmitir, recibir, procesar y almacenar datos de forma confiable. Si hay demasiados problemas
con la confiabilidad del sistema, éste se abandonará.
La distribución de gran potencia de cómputo a individuos incrementa la amenaza a la seguridad debido al
acceso extendido. La necesidad de contraseñas confidenciales, salas de cómputo seguras y capacitación de segu-
ridad adecuada al personal son cuestiones que se multiplican cuando se implementan sistemas distribuidos.
Los analistas de sistemas que crean sistemas distribuidos necesitan enfocarse en la red o en el aspecto coor-
dinado de los sistemas distribuidos. Su poder reside en la capacidad de interactuar como grupos de trabajo de
usuarios que comparten datos. Si el analista de sistemas ignora o resta importancia a la relación entre los subsis-
temas, está creando más problemas de los que está resolviendo. En la figura 16.14 se mencionan las desventajas
de los sistemas distribuidos.
CAPACITACIÓN DE USUARIOS
La capacitación es un proceso educativo en el que participan los analistas de sistemas con los usuarios. El usua-
rio se ha involucrado en todo el ciclo de vida de desarrollo de sistemas, por lo que ahora el analista debe tener
una valoración exacta de los usuarios que se deben capacitar.
• Permiten el almacenamiento remoto de datos en línea y
transacciones en tiempo real
• Permiten un medio menos caro de almacenamiento de
datos cuando los usuarios no los necesitan continuamente
• Reducen el costo de equipo debido a que no todas las partes
del sistema necesitan desempeñar todas las funciones
• Reducen el costo de equipo al permitir la flexibilidad en la
elección de un fabricante
• Al principio son menos costosos que los sistemas grandes
debido a que la expansión se puede planear sin tener que
comprar hardware
Ventajas de los sistemas distribuidos
FIGURA 16.13
Hay cinco ventajas principales en
cuanto a crear sistemas
distribuidos.
• Dificultad para lograr un sistema confiable
• Las preocupaciones de seguridad se incrementan proporcionalmente cuando
más personas tienen acceso al sistema
• Los analistas deben hacer énfasis en la red y las interacciones que ésta
proporciona; además deben restar importancia al poder de los subsistemas
• Escoger el nivel erróneo de cómputo para el soporte (por ejemplo,
personas en lugar de departamentos, departamentos en lugar de
sucursales)
Desventajas de los sistemas distribuidos
FIGURA 16.14
Las cuatro desventajas de los
sistemas distribuidos.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 537
Generalmente, en la implementación de proyectos grandes, el analista administra la capacitación, en lugar
de estar involucrado personalmente en ella. Uno de los recursos más valiosos que el analista puede aportar en
cualquier situación de capacitación es la habilidad de ver el sistema desde el punto de vista del usuario. El ana-
lista nunca debe olvidar lo que es enfrentar un nuevo sistema. Esas recopilaciones pueden ayudar a analistas a
identificarse con los usuarios y facilitar su capacitación.
Estrategias de capacitación
Los factores que determinan las estrategias de capacitación son las personas que serán capacitadas y quiénes las
capacitarán. El analista tendrá que garantizar que cualquiera cuyo trabajo sea afectado por el nuevo sistema de
información sea propiamente capacitado por el instructor correcto.
A QUIÉN CAPACITAR Todas las personas que tendrán uso principal o secundario del sistema deben recibir
capacitación: desde los capturistas hasta aquellos que usarán la salida para tomar decisiones sin usar
personalmente una computadora. La cantidad de capacitación que requiere un sistema depende de cuánto
cambiará el trabajo de alguien debido a las nuevas interacciones requeridas por el nuevo sistema.
Debe asegurarse de que los usuarios con diferentes niveles de habilidad e intereses de trabajo estén separa-
dos. Habrá problemas si incluye a principiantes en las mismas sesiones de capacitación que los expertos, debido
a que los principiantes se pierden con rapidez y los expertos se aburren con los elementos básicos. En consecuen-
cia, ambos grupos se pierden.
PERSONAS QUE CAPACITAN A LOS USUARIOS Para un proyecto grande, se podrían usar muchos instructores
dependiendo de cuántos usuarios se deben capacitar y quiénes son. Las posibles fuentes de capacitación incluyen
lo siguiente:
1. Vendedores.
2. Analistas de sistemas.
3. Instructores externos.
4. Instructores internos.
5. Otros usuarios del sistema.
Esta lista proporciona sólo algunas de las opciones que el analista tiene para diseñar y proporcionar la capacita-
ción.
Con frecuencia, los vendedores grandes proporcionan uno o dos días de sesiones de capacitación sobre su
equipo como parte de los beneficios de servicio ofrecidos cuando las corporaciones compran software COTS
caro. Estas sesiones incluyen conferencias y capacitación práctica en un entorno específico. También pueden ex-
tender la experiencia con grupos de usuarios en línea, blogs dedicados o conferencias anuales de usuarios.
Debido a que los analistas de sistemas conocen a las personas y al sistema de la organización, con frecuencia
pueden proporcionar buena capacitación. El uso de analistas para los propósitos de capacitación depende de su
disponibilidad, debido a que también se espera que vigilen el proceso de implementación completo.
En ocasiones, la organización contrata instructores externos para colaborar en la capacitación. Éstos podrían
tener gran experiencia en capacitar a las personas en cómo usar una variedad de computadoras, pero podrían no
dar la capacitación práctica que algunos usuarios necesitan. Además, tal vez no tengan la capacidad de personali-
zar suficientemente sus presentaciones para hacerlas significativas para los usuarios.
Los instructores internos de tiempo completo con frecuencia están familiarizados con el personal y pueden
adaptar los materiales a sus necesidades. Una de las desventajas de los instructores internos es que podrían tener
experiencia en áreas aparte de los sistemas de información y por consiguiente podrían carecer del alto grado de ex-
periencia técnica que los usuarios requieren.
También es posible asignar a cualquiera de estos instructores para que capacite a un grupo pequeño de per-
sonas de cada área funcional que estará usando el nuevo sistema de información. A su vez, estas personas se pue-
den usar para capacitar al resto de los usuarios. Este enfoque puede funcionar bien si los aprendices originales
todavía tienen acceso a los materiales e instructores como recursos cuando ellos mismos proporcionen la capaci-
tación. De lo contrario, esto podría acabar como una situación de prueba y error en lugar de una estructurada.
Lineamientos para la capacitación
El analista tiene cuatro lineamientos principales para establecer la capacitación: 1) establecer objetivos medibles,
2) usar métodos de capacitación apropiados, 3) seleccionar sitios de capacitación convenientes y 4) emplear ma-
teriales de capacitación entendibles.
OBJETIVOS DE LA CAPACITACIÓN Quien está siendo capacitado dicta, en gran medida, los objetivos de la
capacitación. Es necesario explicar claramente los objetivos de capacitación para cada grupo. Los objetivos
bien definidos son de gran ayuda permitiendo a los aprendices saber lo que se espera de ellos. Además, loswww.xlibros.com

538 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
objetivos permiten evaluación de capacitación cuando están completos. Por ejemplo, los operadores deben saber
dichos elementos esenciales como encender la máquina, qué hacer cuando ocurren errores comunes, solucionar
problemas básicos y cómo acabar un proceso de entrada.
MÉTODOS DE CAPACITACIÓN Cada usuario y operador necesitará capacitación ligeramente diferente. Hasta cierto
punto, sus trabajos determinan lo que necesitan saber, y sus personalidades, experiencia y antecedentes determinan
cómo aprenden mejor. Algunos usuarios aprenden mejor viendo, otros oyendo y otros haciendo. Debido a que
normalmente no es posible personalizar totalmente la capacitación, una combinación de métodos es a menudo la
mejor forma de proceder. Así, se satisface a la mayoría de los usuarios mediante un método u otro.
Los métodos para aquellos que aprenden mejor viendo incluyen demostraciones de equipo y exposición para
manuales de capacitación. Aquellos que aprenden mejor oyendo se beneficiarán de las conferencias sobre los
procedimientos, discusiones y sesiones de preguntas y respuestas entre instructores y aprendices. Aquellos que
aprenden mejor haciendo necesitan experiencia práctica con el nuevo equipo. Para los operadores de computa-
dora, la experiencia práctica es esencial, mientras que un gerente de control de calidad para una línea de produc-
ción sólo podría necesitar ver la salida, aprender a interpretarla y saber cuándo se espera que llegue.
SITIOS DE CAPACITACIÓN La capacitación se lleva a cabo en muchas ubicaciones, algunas de las cuales son más
favorables para aprender que otras. Los grandes vendedores de computadoras proporcionan ubicaciones remotas
especiales donde se mantiene equipo operable en forma gratuita. Sus instructores ofrecen experiencia práctica así
como seminarios en situaciones que permiten a los usuarios concentrarse en aprender el nuevo sistema. Una de
las desventajas de la capacitación remota es que los usuarios están fuera del contexto organizacional en el cual
finalmente deberán operar.
La capacitación en las instalaciones de la organización a la cual pertenecen los usuarios también es posible
con varios tipos diferentes de instructores. La ventaja es que los usuarios ven el equipo tal como estará cuando
sea totalmente operacional dentro del contexto organizacional. Una desventaja seria es que los aprendices con
frecuencia se sienten culpables de no cumplir sus tareas rutinarias de trabajo si permanecen en el lugar de la ca-
pacitación. En estos casos, no se puede lograr una total concentración en la capacitación.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 6 . 4
Puede guiar un pez al agua...
pero no puede hacer que la tome
Sam Monroe, Belle Uga, Wally Ide y usted conforman un equipo
de análisis de sistemas de cuatro miembros que se dedica a desarro-
llar un sistema de información para ayudar a los gerentes a monito-
rear y controlar la temperatura del agua, la cantidad de peces
liberados y otros factores en un gran criadero comercial de peces.
(En la Oportunidad de consultoría 6.3, “Incubar un pez” vimos por
última vez a sus compañeros, cuando le pidieron a usted, en su ca-
lidad de cuarto miembro del equipo, que les ayudara a resolver un
problema relacionado con la entrega a tiempo de un prototipo del
sistema).
Con su participación, el equipo resolvió satisfactoriamente ese
apuro, y el proyecto continúa. Ahora se encuentran discutiendo la
capacitación que han empezado a impartir a los gerentes y otros
usuarios del sistema. A causa de algunos contratiempos con la pla-
nificación, han decidido reducir el número de sesiones de capacita-
ción que impartirán, lo cual ha dado como resultado que en
ocasiones algunos usuarios de varios niveles administrativos y dis-
tintos grados de experiencia con las computadoras se reúnan en las
mismas sesiones de capacitación.
Laurie Hook, una de las operadoras que recibe capacitación,
ha estado en el mismo “tanque” de capacitación con Wade Boot,
uno de los gerentes con quienes usted ha trabajado. Tanto Laurie
como Wade han acudido, cada quien por su parte, a plantear sus
quejas al equipo.
Wade le dijo a usted: “Estoy muy molesto porque tengo que
teclear mis propios datos en las sesiones de capacitación. El Missis-
sippi se congelará antes de que yo haga eso en mi trabajo. Tengo que
saber cuándo esperar la salida y cómo interpretarla cuando llegue.
No invertiré tiempo en las sesiones de capacitación si no puedo
saber eso”.
Laurie, quien comparte las sesiones de capacitación con Wade,
también se quejó con su grupo. “Deberíamos practicar más en las
sesiones de capacitación. Todo lo que hacemos es escuchar mucha
teoría, como en la escuela. Pero no sólo eso, sino que a los gerentes
del grupo les gusta contar una y otra vez las increíbles historias que
les han ocurrido con el viejo sistema. Es aburrido. Lo que yo quiero
es saber cómo operar el sistema. Para mí, es decepcionante porque
no estoy aprendiendo lo que ustedes me dijeron, y aparte de eso, con
todos los jefes ahí, me siento como pez fuera del agua.”
¿Qué problemas se están presentando en las sesiones de capa-
citación? ¿Cómo se pueden resolver, tomando en cuenta los proble-
mas de planificación que se mencionaron? ¿Qué consejos básicos
sobre la preparación de sesiones de capacitación pasó por alto su
equipo? Escriba una respuesta de una página a estas preguntas.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 539
Los sitios de capacitación remota también están disponibles mediante un pago a través de consultores y ven-
dedores. Los sitios de capacitación se pueden establecer en lugares de alquiler tales como un salón de hotel o
instalaciones permanentes mantenidas por los instructores. Estos arreglos permiten a los trabajadores liberarse de
las demandas regulares del trabajo, pero no podrían proporcionar equipo para la capacitación práctica.
MATERIALES DE CAPACITACIÓN En la planeación de capacitación de usuarios, los analistas de sistemas deben
comprender la importancia de los materiales de capacitación bien preparados. Estos materiales incluyen manuales
de capacitación; casos de capacitación, en los cuales los usuarios se asignan para trabajar a través de un caso que
incluye la mayoría de las interacciones normalmente encontradas con el sistema, y prototipos y muestras de
salidas. Los usuarios de sistemas grandes a veces se podrán capacitar en simulaciones detalladas basadas en Web
o software que es idéntico a lo que se escribe o se compra. La mayoría de los vendedores de software COTS
proporciona tutoriales en línea que ilustran las funciones básicas, y los distribuidores podrían mantener sitios
Web que ofrecen páginas dedicadas a responder preguntas frecuentes (FAQ), las cuales se pueden descargar e
imprimir. Los cambios a los manuales también se pueden recabar de los sitios Web de muchos vendedores.
Debido a que el entendimiento del sistema por parte de los usuarios depende de ellos, los materiales de ca-
pacitación se deben escribir claramente para el público correcto con un mínimo de jerga. Los materiales de capa-
citación también deben estar bien indexados y disponibles para cualquiera que los necesite. En la figura 16.15 se
proporciona un resumen de consideraciones para objetivos de capacitación, métodos, sitios y materiales.
CONVERSIÓN A UN NUEVO SISTEMA
Un tercer enfoque para la implementación es convertir físicamente el sistema de información viejo a uno nuevo
o modificado. Hay muchas estrategias de conversión disponibles para analistas y también un enfoque de contin-
gencia que tiene en cuenta diversas variables organizacionales para decidir qué estrategia de conversión usar. No
hay una forma que sea siempre la más apropiada para proceder con la conversión. No podemos subestimar la
importancia de diseñar y programar adecuadamente la conversión (la cual con frecuencia tarda muchas semanas),
el archivo de respaldo y la seguridad adecuada.
Estrategias de conversión
En la figura 16.16 se presentan las cinco estrategias para convertir del sistema viejo al nuevo:
1. Conversión directa.
2. Conversión paralela.
3. Conversión gradual o por fases.
4. Conversión modular.
5. Conversión distribuida.
Cada enfoque de conversión se describe en las siguientes subsecciones.
CONVERSIÓN DIRECTA La conversión directa significa que en una fecha especificada, el sistema viejo se
abandona y el nuevo sistema se pone en uso. La conversión directa puede tener éxito sólo si antes se lleva a cabo
una comprobación extensa, y funciona mejor cuando se pueden tolerar algunos retrasos en el procesamiento. La
conversión directa se considera un enfoque arriesgado para la conversión. Podrían ocurrir trastornos en el entorno
laboral si los usuarios se ofenden porque se les obliga a usar un sistema desconocido sin recursos. Por último, no
hay ninguna forma adecuada para comparar los nuevos resultados con los viejos.
Elementos Factores relevantes
Objetivos de capacitación Dependen de los requerimientos del trabajo del usuario
Sitios de capacitación
Materiales de capacitación
Dependen del trabajo del usuario, personalidad, antecedentes y
experiencia; usa una combinación de conferencia, demostración,
práctica y estudio
Dependen de los objetivos de capacitación, costo, disponibilidad;
sitios gratis del distribuidor con equipo operable; instalaciones
internas; instalaciones alquiladas
Dependen de las necesidades del usuario; manuales operativos, casos,
prototipos de equipos y salida; tutoriales en línea
Métodos de capacitación
FIGURA 16.15
Los objetivos de capacitación,
métodos, sitios y materiales están
sujetos a muchos factores.www.xlibros.com

540 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
CONVERSIÓN PARALELA La conversión paralela se refiere a ejecutar al mismo tiempo el sistema viejo y el nuevo,
en paralelo. Cuando se obtienen los mismos resultados todo el tiempo, el nuevo sistema se pone en uso y el
viejo se detiene. Una ventaja de ejecutar ambos sistemas en paralelo es la posibilidad de verificar los nuevos
datos contra los viejos para percibir cualesquier errores en el procesamiento del nuevo sistema. Las principales
desventajas incluyen el costo de ejecutar dos sistemas al mismo tiempo y el agobio en los empleados de
virtualmente doblar su carga de trabajo durante la conversión.
CONVERSIÓN GRADUAL La conversión gradual, o por fases, intenta combinar las mejores características de los dos
planes previamente mencionados, sin incurrir en todos los riesgos. En este plan, el volumen de las transacciones
manejado por el nuevo sistema aumenta gradualmente conforme el sistema se introduce por fases. Las ventajas
de este método incluyen permitir a usuarios que se involucren gradualmente con el sistema, la posibilidad de des-
cubrir y recuperar errores sin desperdiciar mucho tiempo y la capacidad de agregar características una por una.
Las metodologías ágiles tienden a usar esta metodología de conversión.
CONVERSIÓN MODULAR La conversión modular usa la construcción de subsistemas independientes y ope-
racionales para cambiar de los sistemas viejos a los nuevos de forma gradual. Conforme se modifica y acepta
cada módulo, se pone en uso. Una ventaja es que cada módulo se prueba completamente antes de ser usado.
Otra ventaja es que los usuarios se familiarizan con cada módulo conforme se vuelve operacional. Esta retro-
alimentación ha ayudado a determinar los atributos finales del sistema. Las metodologías orientadas a objetos
utilizan con frecuencia esta metodología.
CONVERSIÓN DISTRIBUIDA La conversión distribuida se refiere a una situación en que se contemplan muchas
instalaciones del mismo sistema, como es el caso en actividades bancarias o franquicias tal como restaurantes
o tiendas de ropa. Una conversión completa se hace (con cualquiera de los cuatro enfoques considerado
previamente) en un sitio. Cuando esta conversión se completa exitosamente, se prosigue con las demás. Una
ventaja de la conversión distribuida es que se pueden detectar y contener un problema antes de que repercuta
simultáneamente en todos los sitios. Una desventaja es que incluso cuando una conversión es exitosa, cada sitio
tendrá su propia gente y cultura, además de sus propias peculiaridades regionales y locales para trabajar, y se
deben manejar en consecuencia.
Otras consideraciones de conversión
La conversión también trae consigo otros detalles para el analista, los cuales incluyen lo siguiente:
1. Pedir equipo (hasta tres meses antes de la conversión planeada).
2. Pedir cualesquier materiales necesarios que se proporcionan externamente al sistema de información, tal
como cartuchos de tinta, papel, formularios impresos previamente y los medios magnéticos.
3. Designar un gerente para supervisar, o supervisar personalmente, la preparación del sitio de la instalación.
Conversión directa
Conversión distribuida
Conversión modular
Conversión gradual
Conversión paralela
Método de conversión Cambios a través del tiempo
FIGURA 16.16
Cinco estrategias de conversión
para los sistemas de información.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 541
4. Planear, fijar y supervisar a programadores y personal de captura de datos que deben convertir todos los
archivos y bases de datos relevantes.
Para muchas implementaciones, su papel principal será estimar con precisión el tiempo necesario para cada
actividad, nombrar a las personas para manejar cada subproyecto y coordinar su trabajo. Para proyectos más
pequeños, hará mucho del trabajo de conversión por usted mismo. Muchas de las técnicas de administración de
proyecto que vimos en el capítulo 3, tal como las gráficas de Gantt, PERT, análisis de puntos de función y la co-
municación exitosa con los miembros del equipo, son útiles para planear y controlar la implementación.
Metáforas organizacionales y su relación con los sistemas exitosos
Esté consciente de las metáforas organizacionales cuando intente implementar un sistema que haya desarrollado
recientemente. Nuestra investigación ha sugerido que el éxito o fracaso de un sistema podrían estar relacionado
con las metáforas que utilizan los miembros de la organización.
Cuando las personas en la organización describen la compañía como un zoológico, puede inferir que la
atmósfera es caótica; si se describe como una máquina, todo está funcionando en un estilo ordenado. Cuando
la metáfora predominante es guerra, expedición o selva, el ambiente también es caótico, aunque las metáforas
guerra y expedición se orientan hacia una meta de la organización, mientras que las metáforas zoológico y
selva no.
Además de máquina, las metáforas tales como sociedad, familia y juego significan orden y reglas. Aunque
las metáforas máquina y juego se orientan a un objetivo, las metáforas sociedad y zoológico no enfatizan el
objetivo de la compañía, sino que permiten a los individuos en la corporación establecer sus propios estánda-
res y premios. Otra metáfora, organismo, parece equilibrada entre orden y caos, objetivos corporativos e indi-
viduales.
Nuestra investigación sugiere que el éxito o fracaso de un sistema podrían tener algo que ver con la metáfora
predominante. La figura 16.17 muestra que un MIS tradicional tenderá a tener éxito cuando la metáfora predomi-
nante sea sociedad, máquina o familia, pero tal vez no podría tener éxito si la metáfora fuera guerra o selva (dos
metáforas caóticas). Sin embargo, hay que tener en cuenta que los sistemas competitivos probablemente tendrán
éxito si la metáfora es guerra.
Las metáforas positivas parecen ser juego, organismo y máquina. Las metáforas negativas parecen ser selva
y zoológico. Las otras (expedición, guerra, sociedad y familia) permiten calcular un nivel de éxito dependiente
del tipo de sistema de información que se desarrolle. Se necesita hacer más investigación en esta área. Mientras
tanto, el analista de sistemas debe estar consciente de que las metáforas comunicadas en las entrevistas podrían
ser significativas e incluso podrían ser un factor de contribución hacia el éxito de la implementación del sistema
de información.
Éxito menos
probable con
estas metáforas
Éxito más
probable con
estas metáforas
Guerra
Jungla
Guerra
Expedición
Jungla
Zoológico
Familia
Sociedad
Máquina
Familia
Sociedad
Organismo
MIS tradicional
Sistema de soporte de decisiones
Sistemas expertos/AI
Sociedad
Zoológico
Zoológico
Familia
Sociedad
Expedición
Zoológico
Juego
Organismo
Máquina
Expedición
Juego
Organismo
Guerra
Juego
Organismo
Organismo
Juego
Sistemas cooperativos
Sistemas competitivos
Sistemas de información ejecutiva
Tipo de sistema de información
FIGURA 16.17
Las metáforas organizacionales
podrían contribuir al éxito o
fracaso de un sistema de
información.www.xlibros.com

542 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
ASPECTOS DE SEGURIDAD PARA LOS SISTEMAS TRADICIONALES
Y LOS BASADOS EN WEB
La seguridad de las instalaciones de cómputo, almacén de datos y la información generada es parte de una con-
versión exitosa. Como vimos en el capítulo 1, el reconocimiento de la necesidad de seguridad es una consecuen-
cia natural de la creencia de que la información es un recurso organizacional importante. Con las transacciones
cada vez más complejas y muchos intercambios innovadores, la Web ha producido un incremento en las preocu-
paciones de seguridad para el mundo profesional de SI.
Es útil pensar en la seguridad de sistemas, datos e información en un continuo imaginario que va desde
seguridad total hasta acceso abierto por completo. Aunque no hay tal cosa como un sistema totalmente seguro,
las acciones de los analistas y usuarios pretenden mover los sistemas hacia el lado más seguro del espectro,
disminuyendo la vulnerabilidad del sistema. Se debe observar que conforme más personas en la organización
obtienen mayor potencia de cómputo, obtienen acceso a la Web, o se conectan a las intranets y extranets, la
seguridad se vuelve cada vez más difícil y compleja. A veces, las organizaciones contratarán a un consultor
de seguridad para trabajar con el analista de sistemas cuando la seguridad es crucial para el funcionamiento
exitoso.
La seguridad es responsabilidad de todos aquellos que están en contacto con el sistema y sólo es tan buena
como la conducta o política menos estricta en la organización. La seguridad tiene tres aspectos interrelacionados:
físico, lógico y conductual. Los tres deben trabajar juntos si deseamos que la calidad de seguridad permanezca
alta.
Seguridad física
La seguridad física se refiere a proteger el sitio donde se encuentra la computadora, su equipo y software a través
de medios físicos. Puede incluir acceso controlado a las salas de cómputo por medio de signos legibles por la
máquina, sistemas biométricos o un registro de entrada y salida del sistema por un humano, así como el uso de
cámaras de televisión de circuito cerrado para supervisar las áreas de cómputo, respaldando con frecuencia los
datos y almacenando los respaldos en un área a prueba de fuego o de agua, a menudo en una ubicación remota
segura.
Además, el equipo de cómputo pequeño se debe asegurar para que un usuario típico no pueda moverlo y se
debe garantizar el suministro ininterrumpido de energía eléctrica. Las alarmas que notifican a las personas apro-
piadas en caso de fuego, inundación o intrusión no autorizada de una persona deben estar en todo momento en
funcionamiento activo.
El analista debe tomar las decisiones acerca de la seguridad física junto con los usuarios cuando esté pla-
neando las instalaciones de cómputo y la compra de equipo. Sin duda la seguridad física puede ser mucho mejor
si se planea con antelación a la instalación real y si las salas de cómputo se dotan de equipo de seguridad especial
al momento de construirlas, en lugar de equiparse después de que se hayan construido.
Seguridad lógica
La seguridad lógica se refiere a los controles lógicos en el software. Los controles lógicos son conocidos por
la mayoría de los usuarios como contraseñas o códigos de autorización de alguna clase. Cuando se usan, per-
miten al usuario entrar al sistema o a una parte específica de una base de datos con una contraseña correcta.
Sin embargo, las contraseñas se manejan de manera descuidada en muchas organizaciones. Los emplea-
dos han escuchado por casualidad gritar una contraseña en las oficinas atestadas, grabar las contraseñas para
sus pantallas y compartir las contraseñas personales con empleados autorizados que han olvidado las suyas.
Se ha desarrollado software de cifrado especial para proteger las transacciones comerciales en Web y las
transacciones comerciales están proliferando. Sin embargo, el fraude de Internet también ha aumentado brusca-
mente, y hay pocas autoridades capacitadas en identificar a los delincuentes y se evidencia una mentalidad de
“salvaje oeste” o “última frontera” en esos casos cuando las autoridades han podido aprehender a los delincuen-
tes de Web.
Una forma para que las redes reduzcan el riesgo de exposición al desafío de la seguridad del mundo ex-
terior es construir un firewall o un sistema similar. Un firewall construye una muralla entre la red interna y la
externa de una organización (tal como Internet). Se asume que la red interna es confiable y segura, mientras
que Internet no lo es. Se pretende que los firewalls impidan la comunicación entrante o saliente de la red que
no haya sido autorizada y que no se requiera. Un sistema firewall no es un remedio perfecto para la seguridad
organizacional y de Internet; sin embargo, es una capa adicional de seguridad que ahora se acepta amplia-
mente. Todavía no hay ninguna forma totalmente integrada de solucionar los problemas de seguridad con laswww.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 543
redes internas y externas, pero merecen la atención de los analistas al diseñar cualquier sistema nuevo o me-
jorado.
Los controles lógicos y físicos son importantes, pero no son suficientemente claros para proporcionar la se-
guridad adecuada. Los cambios conductuales también son necesarios.
Seguridad conductual
Las expectativas conductuales de una organización están implícitas en sus manuales de políticas e incluso en le-
treros anunciados en las salas de trabajo y los comedores, como vimos en el capítulo 5. Sin embargo, la conducta
que los miembros de la organización interiorizan también es crítica para el éxito de los esfuerzos de seguridad
(una razón por la que los firewalls no son totalmente a prueba de ataques es que muchos ataques a los sistemas
de información provienen del interior de la organización).
La seguridad puede empezar con la identificación de empleados que en algún momento tendrán acceso a
las computadoras, datos e información, para asegurar que sus intereses son consistentes con los intereses de la
organización y que entienden por completo la importancia de llevar a cabo los procedimientos de seguridad. Es
necesario escribir, distribuir y actualizar las políticas con respecto a la seguridad para que los empleados estén
totalmente conscientes de las expectativas y responsabilidades. Es típico que el analista de sistemas primero ten-
drá contacto con los aspectos conductuales de la seguridad. Algunas organizaciones han escrito reglas o políticas
que prohíben a los empleados navegar en Web durante horas de trabajo o incluso prohíben totalmente la navega-
ción de Web, si el equipo de la compañía está involucrado. Otras corporaciones usan software de bloqueo para
limitar el acceso a los sitios Web que se consideran inaceptables en el lugar de trabajo, tal como sitios de juegos,
apuestas o pornográficos.
Parte del aspecto conductual de la seguridad es supervisar la conducta a intervalos irregulares para cercio-
rarse de que se están siguiendo los procedimientos apropiados y corregir cualesquier conductas que se podrían
deteriorar con el tiempo. Hacer que el sistema registre el número de inicios de sesión fallidos de los usuarios es
una forma de supervisar si usuarios no autorizados están intentando iniciar sesión en el sistema. Es conveniente
inventariar periódica y frecuentemente el equipo y software. Además, es necesario examinar las sesiones largas
inusuales o el acceso al sistema atípico después de las horas de oficina.
Los empleados deben entender claramente lo que se espera de ellos, lo que se prohíbe y la magnitud de sus
derechos y responsabilidades. Debe comunicar al personal acerca de toda la supervisión que se está haciendo o
que se está contemplando y debe proporcionar la razón para esto. Dicha comunicación debe incluir el uso de cá-
maras de vídeo, monitoreo de software y telefónico.
La salida generada por el sistema se debe reconocer por su potencial de poner a la organización en riesgo en
algunas circunstancias. Los controles para la salida incluyen pantallas que sólo se pueden acceder mediante la
contraseña, la clasificación de información (es decir, a quién se puede distribuir y cuándo) y el almacenamiento
seguro de documentos impresos y almacenados, sin importar el formato.
En algunos casos, es necesario tomar medidas para destruir documentos clasificados o confidenciales. Los
servicios de destrucción o pulverización se pueden contratar con una empresa externa que, por una cuota, des-
truirá medios magnéticos, cartuchos de impresora y papel. Una corporación grande puede destruir anualmente
más de 34,000 kilos de material de salida en una variedad de medios.
Consideraciones especiales de seguridad para el comercio electrónico
Se sabe bien que los intrusos pueden violar la integridad de cualquier sistema de cómputo. Como analista, nece-
sita tomar diversas precauciones para proteger la red de cómputo de las amenazas de seguridad en Web internas
y externas. Varias acciones y productos le pueden ayudar:
1. Software antivirus.
2. Productos de filtración de correo electrónico que proporcionan servicios de exploración y filtrado de correo
electrónico y archivos adjuntos, basado en políticas para proteger a las compañías del correo electrónico
entrante y saliente. La exploración del correo entrante protege contra ataques de spam (correo electrónico no
solicitado, como los anuncios publicitarios) y la exploración del correo saliente protege contra la pérdida de
información propietaria.
3. Productos de filtración de URL que proporcionan a los empleados acceso a Web por usuario, por grupos de
usuarios, por computadoras, por tiempo o por el día de la semana.
4. Firewalls, gateways y redes privadas virtuales que impidan a los hackers acceder a una red corporativa.
5. Productos de detección de intrusión y antiphishing que continuamente supervisan el uso, proporcionan
mensajes e informes y sugieren acciones a tomar.www.xlibros.com

544 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
6. Productos de administración de vulnerabilidad que evalúan los riesgos potenciales en un sistema y
descubren e informan las vulnerabilidades. Algunos productos correlacionan las vulnerabilidades para que
sea más fácil encontrar la raíz de la fuga de seguridad. El riesgo no se puede eliminar, pero este software
puede ayudar a manejarlo al equilibrar el riesgo de seguridad contra los costos de eliminarlos.
7. Tecnologías de seguridad tal como la capa de conexiones seguras (SSL) para la autenticación.
8. Tecnologías de cifrado tales como la transacción electrónica segura (SET).
9. Infraestructura de clave pública (PKI) y certificados digitales (obtenidos de una compañía tal como
Verisign). El uso de certificados digitales asegura que el remitente informado del mensaje realmente sea la
compañía que envió el mensaje.
Consideraciones de privacidad para el comercio electrónico
El otro aspecto de la seguridad es la privacidad. Para hacer su sitio Web más seguro, debe pedir a los usuarios o
clientes que renuncien a cierta privacidad.
Como diseñador de un sitio Web, reconocerá que la empresa para la que usted diseña ejerce mucho poder
sobre los datos que proporcionan sus clientes. Los mismos principios de conducta ética y legal se aplican al di-
seño de sitios Web como al diseño de cualquier aplicación tradicional que acepta datos personales de clientes.
Sin embargo, la Web permite recopilar datos con más rapidez y diferentes (como los hábitos de navegación del
cliente). En general, la tecnología de la información hace posible almacenar más datos en los almacenes de da-
tos, procesarlos y distribuirlos más ampliamente.
Cada compañía para la cual usted diseña una aplicación de comercio electrónico debe adoptar una política
de privacidad. He aquí algunos lineamientos:
1. Inicie con una política corporativa de privacidad. Asegúrese que se despliegue de forma prominente en el
sitio Web para que todos los clientes puedan acceder la política siempre que completen una transacción.
2. Solicite sólo la información que la aplicación requiera para completar la transacción en cuestión. Por
ejemplo, ¿es necesario para la transacción preguntar la edad o género de una persona?
3. Haga opcional para los clientes completar la información personal en el sitio Web. A algunos clientes no les
importa recibir mensajes concretos, pero siempre debe dar una oportunidad a los clientes de mantener la
confidencialidad de sus datos personales al no responder.
4. Use fuentes que le permitan obtener información anónima sobre las clases de clientes. Hay compañías que
ofrecen al público tecnología de perfiles y soluciones de tecnología para administrar los anuncios, sus
objetivos y su entrega. Esto se hace para mantener una base de datos dinámica de perfiles de clientes sin
vincularlos a los individuos, respetando así los derechos de privacidad de los clientes.
5. Sea ético. Evite el uso de trucos baratos que permitan a su cliente recopilar la información sobre el cliente de
formas sospechosas o poco éticas. Los trucos tales como el raspado de pantalla (capturar remotamente lo
que está en la pantalla de un cliente) y la toma de cookies de correo electrónico son violaciones claras de
privacidad; además podrían ser ilegales.
Es esencial una política coordinada de seguridad y de privacidad. Es esencial establecer estas políticas y ad-
herirse a ellas al implementar una aplicación de comercio electrónico.
Planeación de recuperación de desastres
Sin importar con qué diligencia trabajen usted y sus colegas para asegurar la seguridad y estabilidad de los
sistemas, todos los empleados y los sistemas son inevitablemente vulnerables a cierto tipo de desastre natural
o provocado por los humanos, que amenaza tanto la seguridad como el mismo funcionamiento de la empresa.
Algunos desastres son bastante comunes, como los cortes de energía, y podemos evaluar la probabilidad de que
ocurran algunos desastres, como un huracán o terremoto. Sin embargo, muchos otros son inesperados en cuanto
a su ocurrencia o severidad, tal vez incluso hasta provoquen la pérdida de vidas humanas, creando caos para las
personas y la organización en sí.
Los campos relacionados con el grado de preparación y la recuperación contra los desastres son interdepen-
dientes y se basan uno en el otro. El grado de preparación contra desastres incluye lo que una empresa debería
hacer si encuentra una crisis. El campo de la recuperación contra desastres se enfoca en la forma en que una
empresa puede continuar como secuela de un desastre y cómo puede restaurar los sistemas esenciales en la infra-
estructura de TI. Esta sección se enfoca en la recuperación de desastres y su relación con los sistemas de infor-
mación. El proceso tradicional de recuperación de desastres consiste en la planeación, el recorrido, los ejercicios
de práctica y la recuperación del desastre.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 545
Al sufrir un desastre, la empresa se arriesga a perder personas, dinero, reputación y sus propios bienes, así
como los de sus clientes. Es importante hacer lo correcto para minimizar las pérdidas potenciales. Los analistas
deben determinar cuál es el nivel de planeación contra desastres de la organización y qué tan bien articulado está
el rol de sistemas de información en sus planes de respuesta y recuperación en caso de desastres. Las preguntas
clave que se deben hacer los analistas lo antes posible son: 1) si los empleados saben a dónde ir y 2) qué hacer
en caso de un desastre. La respuesta a estas preguntas lo guiará a través del proceso de planeación. La sabiduría
convencional provee siete elementos a considerar durante y después de un desastre. Como veremos, muchos de
estos elementos involucran a los sistemas de información y se relacionan de manera específica con la planeación
que usted debe proveer como analista de sistemas.
1. Identificar los equipos responsables para administrar una crisis.
2. Eliminar puntos individuales de fallas.
3. Determinar las tecnologías de duplicación de datos que coincidan con la agenda de la organización para
poner los sistemas en funcionamiento.
4. Crear planes de reubicación y transportación detallados.
5. Establecer varios canales de comunicación entre los empleados y consultores que están en el sitio, como los
equipos de analistas.
6. Proveer soluciones de recuperación que incluyan una ubicación remota.
7. Asegurar el bienestar físico y psicológico de los empleados y otros que puedan estar físicamente presentes
en el sitio de trabajo cuando ocurra un desastre.
El plan de preparación para desastres debe identificar a los responsables de realizar varias decisiones fun-
damentales en caso de un desastre. Hay que decidir si van a continuar o no las operaciones comerciales; cómo
brindar soporte para las comunicaciones (tanto de computadora como de voz); a dónde se enviarán las personas
si las instalaciones de la empresa son inhabitables; a dónde irá el personal en caso de una emergencia; ocuparse
de las necesidades personales y psicológicas de las personas presentes en la empresa y los que podrían trabajar
en forma virtual; y restaurar los entornos principales de cómputo y laborales.
La redundancia de los datos provee la clave para eliminar puntos individuales de fallas para los servidores
que ejecutan aplicaciones Web. Como analista, usted puede ser especialmente útil para establecer este tipo de
respaldo y redundancia.
Algunas empresas están migrando a las redes de área de almacenamiento (SAN) para evitar parte de la ines-
tabilidad asociada con los respaldos físicos en cintas magnéticas y su almacenamiento. La duplicación remota
sincrónica (también conocida como discos en espejo, o data mirroring) también está ganando popularidad. Pero
si las empresas están a más de 100 millas de distancia del sitio, el proceso de discos en espejo se puede ver afec-
tado. La duplicación remota asíncrona envía datos a la ubicación de almacenamiento secundaria en intervalos de
tiempo designados. Hay opciones en línea para pequeñas empresas también.
La organización debe desarrollar y distribuir a todos un memorándum de una página que contenga las rutas
de evacuación y los puntos de reunión de los empleados. Las tres opciones comunes son enviar a los empleados
a sus casas, hacer que permanezcan dentro de las instalaciones o reubicarlos a una instalación de recuperación
preparada para continuar operando. Hay que tener en cuenta toda la gama de opciones de transportación a la hora
de desarrollar este memo.
Los miembros de la organización y del equipo de análisis de sistemas deben ser capaces de comunicarse en
caso de que se interrumpa el sistema ordinario de correo electrónico. Si no hay correo electrónico disponible para
transmitir un mensaje de emergencia, una página Web con información de emergencia o una línea telefónica
pueden servir para tal fin como alternativas viables. Hace poco, varias empresas de software empezaron a ofre-
cer una suite de herramientas de software que permiten la comunicación ad hoc mediante agencias de respuesta
de emergencia que les permiten establecer con rapidez herramientas de VoIP, conectividad Web y Wi-Fi. La dis-
ponibilidad cada vez más amplia y los precios más bajos sin duda llevarán en el futuro estas importantes herra-
mientas de comunicación a otros tipos de organizaciones.
Para proteger mejor los sistemas de respaldo de la organización y asegurar el flujo continuo de las tran-
sacciones bancarias en caso de un desastre, las nuevas regulaciones en los Estados Unidos estipulan que las
ubicaciones remotas de los bancos deben estar por lo menos a 100 millas de distancia del sitio original. Como
los archivos y respaldos en papel también representan un gran problema y son muy vulnerables a los desastres
naturales y humanos, es imprescindible que las organizaciones creen un plan que les ayude a migrar hacia un
proyecto de documentación digital con el fin de convertir todos sus documentos en papel a formatos electrónicos,
dentro de un plazo de entre tres y cinco años después de su creación (Stephens, 2003).
El soporte para los humanos que trabajan en una organización que experimenta un desastre es algo primor-
dial. Debe haber suficiente agua potable a la que se tenga un fácil acceso, en especial si los empleados no pue-
den salir del sitio durante varios días debido a las condiciones del clima exterior o derrumbamientos parciales de
edificios. Aunque la comida es importante, el agua lo es más. También se debe proporcionar a los empleados unwww.xlibros.com

546 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
kit de seguridad que contenga agua, una mascarilla antipolvo, una linterna, barras luminosas y un silbato. Una
forma de averiguar qué debe contener un kit de provisiones contra desastres para el espacio de trabajo individual
es ir al sitio Web de la Cruz Roja Americana (www.redcross.org), donde se proveen los detalles para apoyar a las
personas en caso de desastres y hacerse cargo de ellas después de los mismos.
EVALUACIÓN
A lo largo del ciclo de vida del desarrollo de sistemas, el analista, los directivos y los usuarios han estado eva-
luando la evolución de los sistemas de información y las redes para proporcionar retroalimentación para su me-
jora eventual. La evaluación también se necesita para dar seguimiento a la implementación del sistema.
Técnicas de evaluación
En reconocimiento de que la evaluación continua de sistemas de información y redes es importante, se han in-
ventado muchas técnicas de evaluación. Estas técnicas incluyen el análisis costo-beneficio (como vimos en el
capítulo 3); los modelos que intentan estimar el valor de una decisión con base en los efectos de la información y
que usan teoría de información, simulación o estadísticas bayesianas; las evaluaciones del usuario que enfatizan
los problemas de implementación y participación del usuario, y los enfoques de utilidad de sistemas de informa-
ción que examinan las propiedades de la información.
Cada tipo de evaluación sirve para un propósito diferente y tiene desventajas inherentes. El análisis costo-
beneficio podría ser difícil de aplicar, debido a que los sistemas de información proporcionan información acerca
de los objetivos para la primera vez, haciendo imposible comparar el desempeño antes y después de la implemen-
tación del sistema o red distribuida. El enfoque de evaluación de decisión revisada presenta dificultad, debido a
que todas las variables involucradas con el diseño, el desarrollo y la implementación del sistema de información
no se pueden calcular o cuantificar. El enfoque de participación del usuario produce algún entendimiento para
los nuevos proyectos al proporcionar una lista de control de la conducta potencialmente disfuncional por varios
miembros organizacionales, pero enfatiza la implementación sobre otros aspectos del diseño del SI. El enfoque
de utilidad del sistema de información para la evaluación puede ser más completo que otros si se extiende y se
aplica de manera sistemática.
El enfoque de utilidad del sistema de información
El enfoque de utilidad del sistema de información para evaluar los sistemas de información puede ser una técnica
completa y fructífera para medir el éxito de un sistema desarrollado. También puede servir como una guía en el
desarrollo de cualesquier proyectos futuros que el analista podría emprender.
Las utilidades de información incluyen posesión, forma, lugar y tiempo. Para evaluar el sistema de infor-
mación integralmente, estas utilidades se deben extender para incluir utilidad de actualización y utilidad del
objetivo. Después las utilidades se pueden ver para responder adecuadamente las preguntas de quién (posesión),
qué (forma), dónde (lugar), cuándo (tiempo), cómo (actualización) y por qué (objetivo). En la evaluación de un
sistema de inventario de sangre de la figura 16.18 se puede ver un ejemplo de este enfoque de utilidad de infor-
mación.
Podemos evaluar un sistema de información como exitoso si posee las seis utilidades. Si el módulo del sis-
tema se juzga como “pobre” al proveer una de las utilidades, todo el módulo estará destinado a fracasar. Una ob-
tención parcial de “regular” en una utilidad producirá un módulo parcialmente exitoso. Si el módulo del sistema
de información se juzga como “bueno” al proveer todas las utilidades, el módulo se considera un éxito.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 6 . 5
El dulce aroma del éxito
Recuerde que en la Oportunidad de consultoría 3.1, “El sonido
más dulce que haya sorbido”, conoció a Felix Straw. Diseñe una
solución de sistemas que resuelva los problemas que se plantearon
en ese capítulo. (Sugerencia: La tecnología es importante, pero
también lo es la forma en que la utilice |a gente.). Su solución deberá
enfatizar la colaboración, flexibilidad, adaptabilidad y el acceso. Use
diagramas de red para ilustrar su solución. En unos párrafos, explique
de manera lógica por qué debe elegirse su solución.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 547
UTILIDAD DE POSESIÓN La utilidad de posesión responde la pregunta de quién debe recibir la salida o, dicho de otro
modo, quién debe ser responsable de tomar las decisiones. La información no tiene valor en posesión de al guien
que carece de poder para hacer mejoras en el sistema o carece de habilidad de usar la información en forma
productiva.
UTILIDAD DE FORMA La utilidad de forma responde la pregunta de qué tipo de salida se distribuye al encargado
de tomar decisiones. Los documentos deben ser útiles para una persona específica encargada de tomar decisiones
en lo que se refiere al formato y a la jerga del documento usados. Los acrónimos y títulos de columna deben
ser significativos para el usuario. Además, la información debe estar en un formato apropiado. Por ejemplo, el
usuario no debe tener que dividir un número entre otro para obtener un porcentaje. En cambio, un porcentaje
se debe calcular y desplegar claramente. Al otro extremo está la presentación de muchos datos irrelevantes. La
sobrecarga de información ciertamente disminuye el valor de un sistema de información.
UTILIDAD DE LUGAR La utilidad de lugar responde la pregunta de dónde se distribuye la información. La
información se debe entregar en el lugar donde se tomó la decisión. Se deben archivar o almacenar informes más
detallados o informes de administración anteriores para facilitar el acceso futuro.
UTILIDAD DE TIEMPO La utilidad de tiempo responde la pregunta de cuándo se distribuye la información. La
información debe llegar antes de que se tome una decisión. La información retrasada no tiene utilidad. Al otro
extremo está la entrega de información mucho tiempo antes de la decisión. Los informes se podrían volver
inexactos o podrían olvidarse si se entregaron prematuramente.
UTILIDAD DE ACTUALIZACIÓN La utilidad de actualización está relacionada con cómo el encargado de tomar
decisiones introduce la información y la utiliza. Primero, el sistema de información tiene valor si posee la
Módulos de
sistemas de
información
Utilidad de
forma
Utilidad de
tiempo
Utilidad de
lugar
Utilidad de
posesión
Utilidad de
actualización
Utilidad de
objetivo
Listas de
inventario
Éxito
Bueno. Acrónimos
usados donde son
iguales que los códigos
de envío. Conforme
crece un sistema, se
presenta demasiada
información; esta
sobrecarga se hizo para
resumir la información.
Pobre. Las personas
que asignan la sangre
desconfían de los
misteriosos números
producidos por la
computadora.
Bueno. Los
informes se
recibieron por lo
menos una hora
antes de que se
programaran los
envíos en una
base diaria.
Bueno. Las listas de
inventario se
imprimieron en el
centro regional de
sangre. Las listas se
entregaron a los
hospitales con los
envíos actuales.
Bueno. La
implementación fue
fácil debido a que los
hospitales encontraron
las listas de inventarios
extremadamente útiles.
Bueno. Los informes
los recibieron las
mismas personas
que originalmente
mantuvieron los
registros manuales.
Bueno. La
información acerca
de la ubicación de
una unidad
particular estuvo
disponible.
Pobre. Ésta no fue
una meta inmediata
de la región del
banco de sangre.
Los costos de envío
se pasaron a los
pacientes.
Pobre. Hubo
demasiadas personas
involucradas con los
inventarios de sangre
para participar en el
diseño del sistema.
Regular. Los
administradores
responsables de
asignar a diario la
sangre recibieron el
original.
Bueno. Se imprimieron
en el banco de sangre.
Bueno. Los
informes se
proporcionaron
una hora antes de
que se tomaran
las decisiones.
Asignación
heurística
Falla
Bueno. Se
previnieron
ausencias al llamar
a más donadores.
Bueno. El diseño de
la salida pudo haber
sido más participativo.
Bueno. Los
administradores
involucrados con la
distribución y
recolección reciben
el informe.
Bueno. Se imprimieron
en el banco de sangre.
Bueno. Los
pronósticos se
actualizaron a
diario.
Bueno. Se emitió un
pronóstico para cada
tipo de sangre.
Pronóstico a
corto plazo
Éxito
Bueno. Los informes
de resumen
ayudaron a reducir
obsolescencias y
evitar escasez.
Bueno. Los
administradores de
sangre participaron en
el diseño de los
informes.
Bueno. Los
administradores de
sangre que
originalmente
mantienen los
informes manuales
recibieron estos
reportes.
Bueno. Los informes
de resumen se
imprimieron en
el centro donde
se necesitaban.
Bueno. Igual que
los listados.
Bueno. El informe de
resumen se diseñó para
las especificaciones de
formato exactas de los
informes de resumen
manuales desarrollados
por el administrador de
sangre de los hospitales
de la ciudad.
Informes de
resumen de
la gerencia
Éxito
FIGURA 16.18
Evaluación de información de inventario de sangre y de un sistema de soporte de
decisiones mediante el enfoque de utilidad de un sistema de información.www.xlibros.com

548 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
habilidad de ser implementado. Segundo, la utilidad de actualización implica que un sistema de información
tiene valor si se mantiene después de que sus diseñadores se van, o si un usuario que utilice por una sola vez el
sistema de información obtiene resultados satisfactorios y duraderos.
UTILIDAD DE OBJETIVO La utilidad de objetivo responde el “porqué” de los sistemas de información al preguntar
si la salida tiene el valor de ayudar a la organización a cumplir sus metas. El objetivo del sistema de información
no sólo debe estar en línea con los objetivos de los encargados de tomar decisiones, sino que también debe
reflejar sus prioridades.
EVALUACIÓN DE SITIOS WEB CORPORATIVOS
La evaluación del sitio Web corporativo que está desarrollando o manteniendo es una parte importante de cual-
quier esfuerzo de implementación exitoso. Los analistas pueden usar el enfoque de utilidad del sistema de infor-
mación previamente descrito para evaluar las calidades estéticas, contenido y entrega del sitio. Como analista o
administrador Web, debe ir un paso más adelante y analizar el tráfico Web.
Un visitante a su sitio Web puede generar gran cantidad de información útil para que usted la analice. Esta
información se puede recopilar automáticamente al capturar información sobre la fuente, incluyendo el último si-
tio Web que el usuario visitó y las palabras clave usadas para encontrar el sitio; la información también se puede
obtener mediante el uso de cookies (archivos colocados en la computadora de un visitante acerca de cuándo vi-
sitó por última vez el sitio).
Uno de los principales paquetes para monitorear actividad de Web es Webtrends. La figura 16.19 es una
muestra de un reporte que lista los archivos más descargados en el sitio Web por día de la semana. El gráfico
muestra los primeros cinco archivos transmitidos y la tabla inferior es una lista ordenada de todas las descargas.
Un analista o administrador Web pueden obtener información valiosa al usar un servicio tal como Webtrends
(aunque algunos servicios son gratuitos, por lo general los servicios de pago proporcionan el detalle necesario
para evaluar a fondo el sitio; el costo se considera un costo de operación para el mantenimiento del sitio Web).
La información para ayudarle a evaluar el sitio de su cliente y hacer mejoras es abundante y fácil de obtener. Los
siete elementos esenciales se describen a continuación.
1. Sepa con qué frecuencia se visita el sitio Web de su cliente Entra la información general que debe saber
figuran el número de consultas que tuvo un sitio Web en los últimos días, el número de sesiones de visitantes
y el número de páginas visitadas.
2. Aprenda detalles acerca de páginas específicas en el sitio Es posible obtener estadísticas de las páginas
más solicitadas, los temas más solicitados, las rutas superiores que un visitante sigue a través del sitio Web
del cliente o incluso los archivos más transmitidos. Si el sitio Web es comercial, los informes del carrito de
compras pueden mostrar cuántos visitantes se convirtieron en compradores y cuántos abandonaron sus
carritos o no completaron el proceso de pago.
O P O R T U N I D A D D E C O N S U L T O R Í A 1 6 . 6
Limpiando el nuevo sistema
“No sé lo que pasó. Cuando se instaló el nuevo sistema, los
analistas salieron limpiamente, hasta donde puedo recordar”, dice
Marc Schnieder, en tono filosófico. Como vimos, él es dueño de Marc
Schnieder Janitorial Supply Company (usted vio a Marc por última
vez en la Oportunidad de consultoría 13.1, cuando le ayudó a so-
lucionar sus necesidades de almacenamiento de datos. En ese
lapso, en la empresa de Marc instalaron un nuevo sistema de infor-
mación).
“El equipo de análisis de sistemas nos hizo algunas preguntas
sobre qué nos había parecido el nuevo sistema”, Marc agrega con
impaciencia. “Nunca supimos cómo decirles que la salida no era tan
limpia como hubiéramos querido. Es decir, era confusa. Por ejem-
plo, no le llegaba a la gente adecuada en el momento oportuno. En
realidad nunca pudimos discutir de los pequeños detalles del sis-
tema terminado con ese equipo de consultores. Siento como si hu-
biéramos tenido que contratar a su grupo simplemente para que
limpiaran lo que ellos ensuciaron”.
Después de posteriores conversaciones con Stan Lessink y Jill
Oh, los programadores en jefe de la compañía, usted llega a la con-
clusión de que el equipo que hizo la instalación inicial no tenía nin-
gún mecanismo de evaluación. Sugiera un marco de trabajo adecuado
para evaluar las inquietudes que le surgieron al señor Schnieder so-
bre el sistema. ¿Qué problemas pueden ocurrir cuando un sistema no
se evalúa de manera sistemática? Responda en un párrafo.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 549
3. Averigüe más sobre los visitantes del sitio Web La demografía e información del visitante —tal como el
número de visitas por un visitante particular en un periodo, si el visitante es nuevo o es uno que está
regresando, y quiénes son los visitantes más frecuentes— es información valiosa al evaluar un sitio Web. La
pantalla en la figura 16.20 muestra el número de los visitantes únicos (gráfico superior), el número de
visitantes que realizan su primera visita (gráfico medio) y la duración media de las visitas (gráfico inferior).
4. Descubra si los visitantes pueden completar adecuadamente los formularios que diseñó Si el porcentaje de
error es alto, rediseñe el formulario y vea lo que sucede. El análisis de las estadísticas revelará si un mal
diseño de formulario puede ser culpable por los errores en las respuestas.
5. Averigüe quién envía a los visitantes del sitio Web al sitio del cliente Averigüe cuáles sitios son
responsables de enviar a los visitantes al sitio Web del cliente. Consiga estadísticas de los sitios que le han
enviado más tráfico, los motores de búsqueda más efectivos e incluso las palabras clave que los visitantes
usaron para localizar el sitio Web de su cliente. Después de promover un sitio, puede usar el análisis de
tráfico Web para rastrear si la promoción del sitio realmente representó una diferencia.
FIGURA 16.19
Ejemplo de un informe de
Webtrends Corporation que
muestra los archivos que más se
descargaron en el sitio Web
corporativo.
FIGURA 16.20
Informe que compara las
estadísticas de los visitantes
generadas por Commerce Trends
(de Webtrends Corporation).www.xlibros.com

550 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
6. Determine qué navegadores están usando los visitantes Sabiendo qué navegadores se están usando, puede
agregar características de un navegador específico que mejoren la apariencia y el funcionamiento del sitio, y
animen a los visitantes a quedarse más tiempo, con lo cual mejora la lealtad del sitio. Esto ayuda a saber si
los visitantes están usando navegadores actuales o anticuados.
7. Averigüe si los visitantes del sitio Web del cliente están interesados en la publicidad Por último, averigüe si
los visitantes del sitio están interesados en las campañas publicitarias que tiene en su sitio, tal como ofrecer
un descuento especial a productos por un periodo específico.
Los servicios de monitoreo de actividad Web pueden ser útiles al evaluar si el sitio está cumpliendo con
sus objetivos en lo que se refiere al tráfico, a la efectividad de la publicidad, la productividad del empleado y el
retorno sobre la inversión. Ésta es una de las maneras en que un analista puede evaluar si la presencia Web cor-
porativa está cumpliendo con las metas fijadas por la gerencia y si se cumple con precisión con la visión de la
organización.
RESUMEN
El analista de sistemas puede asegurar la administración de la
calidad total (TQM) para analizar y diseñar sistemas de infor-
mación de muchas formas. Seis Sigma es una cultura, filosofía,
metodología y un enfoque para la calidad que tiene como meta
la eliminación de todos los defectos. Una herramienta para
diseñar un sistema con un enfoque descendente y modular se
denomina diagrama de estructura. La arquitectura orientada
a servicios es una metodología que utiliza servicios indepen-
dientes para realizar varias funciones. Dos de las técnicas es-
tructuradas que pueden ayudar al analista de sistemas son los
manuales de procedimientos y FOLKLORE. Los analistas de
sistemas deben elegir una técnica que se adapte bien a lo que se
utilizaba anteriormente en la organización; además debe permi-
tir flexibilidad y una fácil modificación.
La prueba de programas específicos, subsistemas y siste-
mas totales es esencial para la calidad. El mantenimiento del
sistema es una consideración importante. Los auditores inter-
nos y externos se usan para determinar la fiabilidad de la in-
formación del sistema. Ellos comunican sus resultados de la
auditoría a otros para mejorar la utilidad de la información del
sistema.
La implementación es el proceso de asegurar que los siste-
mas de información y las redes sean funcionales y después in-
volucrar a los usuarios bien capacitados en su operación. En los
proyectos grandes de sistemas, el papel principal del analista es
vigilar la implementación, estimando correctamente el tiempo
necesario, y después supervisar la instalación del equipo para
los sistemas de información.
Los sistemas distribuidos aprovechan la tecnología de las
telecomunicaciones y de administración de bases de datos para
interconectar a las personas que manipulan algunos de los mis-
mos datos de formas significativas pero diferentes. Conforme se
evalúan el hardware y software, el analista de sistemas también
necesita considerar los costos y beneficios de emplear un sis-
tema distribuido para satisfacer los requerimientos del usuario.
Una de las formas más populares de acercarse a los sistemas
distribuidos es mediante el uso de un modelo cliente-servidor.
La computación en nube permite dar servicio al comercio, las
aplicaciones y el almacenamiento de datos mediante Internet.
Los tipos estándar de redes organizacionales incluyen la red de
área local (LAN) y la red de área amplia (WAN). Mediante la
metodología descendente (top-down) los analistas pueden usar
cinco símbolos para ayudar a dibujar diagramas de descompo-
sición de red y de conectividad de concentradores.
La capacitación de usuarios y personal para interactuar con
el sistema de información es parte importante de la implemen-
tación, debido a que los usuarios generalmente deben poder
ejecutar el sistema sin la intervención del analista. La conver-
sión es el proceso de cambiar del sistema de información viejo
al nuevo. Las cinco estrategias de conversión son conversión
directa, conversión paralela, conversión por fases o gradual,
conversión modular y conversión distribuida. La investigación
sugiere que los analistas pueden mejorar la probabilidad de que
se acepten los sistemas recién implementados si desarrollan
sistemas teniendo en cuenta metáforas organizacionales predo-
minantes.
La seguridad de datos y sistemas ha cobrado mayor im-
portancia para los analistas que diseñan más aplicaciones de
comercio electrónico. La seguridad tiene varias facetas —fí-
sica, lógica y conductual— que deben trabajar en conjunto. Los
analistas pueden tomar varias precauciones, tal como software
antivirus, filtrado de correo electrónico, filtros URL, firewalls,
gateways, redes privadas virtuales, productos de detección de
intrusión, nivel de sockets seguros, transacción electrónica
segura y el uso de una infraestructura de clave pública para
mejorar la privacidad, confidencialidad y seguridad de siste-
mas, redes, datos, individuos y organizaciones. Además, toda
empresa para la cual usted diseñe una aplicación de comercio
electrónico debe adoptar una política de privacidad con base en
cinco lineamientos.
Incluso cuando se tomen todas las medidas posibles para
asegurar la seguridad, privacidad y estabilidad del sistema,
todos los empleados y sistemas son vulnerables a los desas-
tres naturales o provocados por los humanos. La recuperación
de los desastres se concentra en la forma en que una empresa
puede continuar después de sufrir un desastre y cómo puede
restaurar la infraestructura esencial de TI.
Hay muchos enfoques de evaluación disponibles, inclu-
yendo el análisis costo-beneficio, el enfoque de evaluación de
decisión revisada y las evaluaciones de la participación del usua-
rio. El marco de referencia de la utilidad del sistema de infor-
mación es una forma directa de evaluar un nuevo sistema con
base en las seis utilidades de posesión, forma, lugar, tiempo,
actualización y objetivo.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 551
E X P E R I E N C I A D E H Y P E R C A S E ® 1 6 . 2
“Como sabe, Snowden está decidido a implementar algún tipo
de rastreo automatizado para la gente de Capacitación. No obstante,
a pesar de que usted y su equipo han estado aquí en MRE todo este
tiempo, a mí no me queda claro cómo se logrará eso. Tal vez usted
se haya percatado que algunas personas como Tom Ketcham se
aferran a sus formas de pensar, pero Snowden también es así, y él
tiene la sartén por el mango. Lo que le estoy diciendo no es nuevo
para usted, ¿verdad?”.
“Además le pido que verifique con Jack O’Malley y Kate Eckert
para asegurarse de que lo que planea esté cubierto por su plan de
recuperación de desastres más reciente. Creo que para cuando
Snowden regrese de Polonia, usted debe estar preparado para mos-
trarle cómo podemos implementar un sistema de rastreo automati-
zado para el grupo de Capacitación, pero tiene que ser un sistema
convincente para los nuevos usuarios. Después de todo, ellos son
los que tienen que utilizarlo. Le reservaré una reunión con Snowden
para dentro de dos semanas.”
Preguntas de HYPERCASE
1. Desarrolle un plan de implementación que pudiera servir al
grupo de Capacitación para cambiar a un sistema
computarizado de rastreo de proyectos. Explique su enfoque
en un párrafo. Asegúrese de que su plan también cumpla las
expectativas de Snowden.
2. En dos párrafos, explique qué enfoque de conversión es
apropiado para adoptar un nuevo sistema automatizado de
seguimiento de proyectos para el grupo de Capacitación.
3. Cree una lista con viñetas de las medidas que tomaría para
asegurar y respaldar el nuevo sistema de rastreo de proyectos
que va a proponer para el grupo de Capacitación.
PALABRAS CLAVE Y FRASES
acoplamiento de datos
administración de la calidad total (TQM)
análisis del tráfico Web
auditor interno
bandera de control (interruptor)
círculo de calidad de SI
conectividad de concentrador
conversión directa
conversión distribuida
conversión gradual o en fases
conversión modular
conversión paralela
descomposición de red
diagrama de estructura
diseño ascendente
diseño descendente
diseño y desarrollo modular
documentación de software
firewall o sistema de firewall
FOLKLORE
infraestructura de clave pública (PKI)
mantenimiento de software
metáforas organizacionales
modelado de redes
modelo cliente-servidor
política de privacidad corporativa
preparación para desastres
procesamiento distribuido
productos de filtrado de correo electrónico
productos de filtrado de URL
prueba de sistemas completa con datos de prueba
prueba de sistemas completa con datos reales
prueba de vínculos con datos de prueba (prueba de cadena)
prueba del programa con datos de prueba
recorrido estructurado
recuperación de desastres
red de área amplia (WAN)
red de área local (LAN)
red de área local inalámbrica (WLAN)
redes de área de almacenamiento (SAN)
seguridad conductual
seguridad lógica
Seis Sigma
software antivirus
software de cifrado
utilidad del sistema de información
verificación de escritorio
PREGUNTAS DE REPASO
1. ¿Cuáles son las tres metodologías amplias disponibles para que el analista de sistemas obtenga calidad en los sistemas
recién desarrollados?
2. ¿Qué o quién es el factor más importante para establecer y evaluar la calidad de los sistemas de información o sistemas
de soporte de decisiones? ¿Por qué?
3. Defina la metodología de administración de la calidad total (TQM) según su aplicación al análisis y diseño de sistemas
de información.www.xlibros.com

552 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
4. ¿Qué significa el término Seis Sigma?
5. ¿Qué es un círculo de calidad de SI?
6. Defina lo que significa realizar un recorrido estructurado. ¿Qué debe estar involucrado? ¿Cuándo se deben realizar los
recorridos estructurados?
7. Mencione las ventajas de tomar una metodología descendente para el diseño.
8. Defina el desarrollo modular.
9. Mencione cuatro lineamientos para la programación modular correcta.
10. Nombre los dos tipos de flechas utilizadas en los diagramas de estructura.
11. ¿Qué es la arquitectura orientada a servicios?
12. Mencione dos razones que apoyen la necesidad de sistemas documentación de software bien desarrollados.
13. ¿En qué cuatro categorías recolecta información el método de documentación FOLKLORE?
14. Mencione seis lineamientos para elegir una técnica de diseño y documentación.
15. ¿Quién tiene como principal responsabilidad probar los programas de computadora?
16. ¿Cuál es la diferencia entre los datos de prueba y los datos reales?
17. ¿Cuáles son los dos tipos de auditores de sistemas?
18. Mencione las cuatro metodologías para la implementación.
19. Describa lo que significa un sistema distribuido.
20. ¿Cuál es el modelo cliente-servidor?
21. Describa cuál es la diferencia entre un cliente y un usuario.
22. ¿Cuáles son las ventajas de utilizar una metodología cliente/servidor?
23. ¿Cuáles son las desventajas de usar una metodología cliente/servidor?
24. ¿Quién se debe capacitar para usar el sistema de información nuevo o modificado?
25. Mencione las cinco posibles fuentes de capacitación para los usuarios de sistemas de información.
26. Mencione las cinco estrategias de conversión para convertir sistemas de información antiguos en nuevos.
27. Mencione las nueve metáforas organizacionales y el éxito hipotético de cada tipo de sistema dada su presencia.
28. Defina los términos seguridad física, lógica y conductual y dé un ejemplo de cada uno que ilustre las diferencias entre
ellos.
29. Defina lo que significa software de cifrado.
30. ¿Qué es un firewall o sistema de firewall?
31. Mencione cinco de las medidas que un analista puede tomar para mejorar la seguridad, privacidad y confidencialidad de
datos, sistemas, redes, individuos y organizaciones que usan aplicaciones Web de comercio electrónico.
32. Mencione cinco lineamientos para diseñar una política de privacidad corporativa para las aplicaciones de comercio
electrónico.
33. Mencione brevemente las diferencias entre preparación para desastres y recuperación de desastres.
34. Mencione y describa las utilidades de los sistemas de información que se pueden utilizar para evaluar el sistema de
información.
35. ¿Cuáles son los siete elementos esenciales que el analista debe incluir al realizar el análisis de tráfico de un sitio Web?
PROBLEMAS
1. Uno de los miembros de su equipo de análisis de sistemas ha estado desalentando los comentarios de los usuarios
sobre los estándares de calidad, argumentando que debido a que ustedes son los expertos, realmente son los únicos
que saben lo que constituye un sistema de calidad. En un párrafo, explique al miembro de su equipo por qué es
importante obtener las opiniones de los usuarios para la calidad del sistema. Use un ejemplo.
2. Escriba una tabla de contenido detallada para un manual de procedimientos que explique a los usuarios cómo conectarse
a la red de cómputo de su escuela, así como también las políticas de la red (quién es un usuario autorizado, etc.).
Asegúrese de que el manual se escriba pensando en el usuario.
3. Su equipo de análisis de sistemas está cerca de completar un sistema para Meecham Feeds. Roger está bastante seguro
de que los programas que ha escrito para el sistema de inventario de Meecham funcionarán como se requiere, debido a
que son similares a los programas que ha hecho antes. Su equipo ha estado muy ocupado y le gustaría empezar a realizar
la prueba completa de sistemas tan pronto como sea posible. Dos miembros jóvenes de su equipo han propuesto lo
siguiente:
a. Omitir la verificación de escritorio de los programas (debido a que programas similares se verificaron en otras
instalaciones; Roger está de acuerdo).
b. Hacer la prueba de vínculos con grandes cantidades de datos para comprobar que el sistema funcionará.
c. Hacer la prueba completa de sistemas con grandes cantidades de datos reales para demostrar que el sistema está
funcionando.
Responda a cada uno de los tres pasos del programa de prueba propuesto. Explique su respuesta en un párrafo.
4. Proponga un plan de pruebas modificado para Meecham Feeds (problema 3). Divida su plan en una secuencia de pasos
detallados.
5. Dibuje una red de área local, o alguna otra configuración de procesamiento distribuido que use el enfoque cliente/
servidor, para resolver algunos de los problemas con la compartición de datos que está teniendo la compañía dewww.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 553
construcción Bakerloo Brothers. La empresa quiere que equipos de arquitectos trabajen en diseños en la oficina
principal, permitir al supervisor de la construcción introducir los cambios de último momento a los planos de obras en
proceso y permitir a clientes ver los diseños casi en cualquier parte. Actualmente, la compañía tiene una LAN para los
arquitectos que están en una ciudad (Filadelfia) que les permite compartir algunas herramientas de dibujo y cualquier
actualización que los miembros del equipo hacen con los arquitectos en otras ciudades (Nueva York, Terre Haute,
Milwaukee, Lincoln y Vancouver). El supervisor usa una computadora portátil, no puede hacer ningún cambio y no se
conecta a una base de datos. Los clientes ven los diseños en las pantallas, pero los representantes de ventas no pueden
introducir las modificaciones para mostrarles lo que pasaría si una pared se moviera o si se alterara una línea del tejado
(Sugerencia: Mencione los problemas que la compañía está encontrando, analice los síntomas, piense en una solución y
después empiece a dibujar.). Se podría necesitar más de una red y no todos los problemas se prestan a una solución de
sistemas.
6. Cree un plan de recuperación de desastres para una de las redes que recomendó a Bakerloo Brothers en el problema 5.
7. Cramtrack, el sistema de tren regional, está intentando capacitar a los usuarios de su sistema de cómputo recién
instalado. Para que los usuarios obtengan la capacitación adecuada, los analistas de sistemas involucrados con el
proyecto enviaron un memorándum a los jefes de los cuatro departamentos que incluye a usuarios principales y
secundarios. El memorándum decía en parte, “Sólo las personas que sienten que requieren capacitación necesitan hacer
las reservaciones para la capacitación externa; todos los demás deben aprender el sistema conforme trabajen con él”.
Sólo se inscribieron 3 usuarios de 42 posibles. Los analistas están satisfechos de que el memorándum separó
eficazmente a las personas que necesitan la capacitación de aquellos que no la necesitan.
a. En un párrafo, explique qué puede estar mal en el enfoque que los analistas siguieron para capacitar.
b. Delinee los pasos que seguiría para asegurar que las personas correctas de Cramtrack están capacitadas.
c. En un párrafo sugiera cómo se debería usar la Web para ayudar en la capacitación para Cramtrack.
8. Al escritorio de Bill Cornwell llegó un atractivo y colorido folleto donde se describe el programa de capacitación externa
y las instalaciones de la Benny Company en términos muy favorables, mostrando usuarios felices frente a sus PC e
instructores profesionales atendiéndoles con aspecto interesado. Bill se dirigió agitadamente hacia la oficina de Roseann
y le dijo: “Tenemos que contratarlos. ¡Este lugar se ve excelente!”. Roseann no se convenció por el folleto, pero no supo
qué decir en defensa de la capacitación interna para usuarios que ella ya había autorizado.
a. En unas frases, ayude a Roseann a argumentar la utilidad de la capacitación interna con instructores internos en
comparación con la capacitación externa con instructores contratados externamente.
b. Si Bill se decide por la capacitación de la Benny Company, ¿qué debe hacer para verificar que esta compañía sea de
hecho el lugar correcto para capacitar a los usuarios del sistema de información de la compañía? Haga una lista de
acciones que deba seguir.
9. “Sólo un poco más... Quiero estar seguro que está trabajando correctamente antes de que cambie de opinión”, dice
Buffy, la dueña de tres boutiques de accesorios de baño de nombre Tub’n Stuff. Su contador, quien le ayudó a establecer
un nuevo sistema de información de contabilidad, está intentando desesperadamente persuadir a Buffy de migrar
completamente hacia el nuevo sistema. Buffy ha insistido en ejecutar los sistemas antiguo y nuevo en paralelo durante
un año entero.
a. Describa brevemente los problemas generales involucrados al usar una estrategia de conversión paralela para
implementar un nuevo sistema de información.
b. En un párrafo, intente convencer al dueño de Tub’n Stuff de que un año para ejecutar un sistema en paralelo es
mucho tiempo. Sugiera una forma de acabar los sistemas duales de Tub’n Stuff que proporcione bastante certeza a
Buffy (asuma que el nuevo sistema es confiable).
10. Delinee un plan para realizar el análisis de tráfico Web para la aplicación de comercio electrónico desarrollada para
Marathon Vitamin Shops (consulte las Oportunidades de consultoría 1.1, 13.2 y 14.6 para conocer más sobre la
organización, sus productos y sus objetivos). Su diseño debe tomar la forma de un informe escrito para el dueño de la
cadena, Bill Berry. Asegúrese de indicar qué estadísticas supervisará y por qué es importante que Marathon Vitamin
Shops las conozca.
11. FilmMagic, una cadena de tiendas de renta de video, está experimentando con agregar un nuevo servicio basado en Web
a su tienda (similar a www.netflix.com) que podría, por una cuota mensual, permitir a clientes escoger una lista de
DVD, prepararlos para enviarlos a su casa y regresarlos en un sobre prepagado cuando los hayan visto. Con base en lo
que sabe de FilmMagic, escriba una política de privacidad corporativa que funcionaría bien en su sitio Web
recientemente propuesto. Cree una pantalla de prototipo (con un paquete de gráficos o un procesador de texto) que
incluya lenguaje apropiado, fuentes e iconos para mostrar cómo aparecerá su política como una página en el sitio Web
de FilmMagic.
12. Ayman’s Office Supplies Company mandó instalar hace poco un nuevo sistema de información para ayudar a sus
gerentes con el inventario. Al con ellos, usted observa que parecían enfadados con la salida del sistema, una serie de
pantallas que muestran el inventario actual, direcciones del cliente y proveedor, y otros datos. Se necesita acceder a todas
las pantallas a través de varios comandos especiales y el uso de una contraseña. Los gerentes tuvieron varias opiniones
sobre el sistema pero no tuvieron ninguna forma sistemática de evaluarlo.
a. Invente una lista de control o formulario que ayude a los gerentes de Ayman a evaluar las utilidades de un sistema de
información.
b. Sugiera una segunda forma de evaluar el sistema de información. Compárela con lo que hizo en el problema 12a.www.xlibros.com

554 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
PROYECTOS EN GRUPO
1. Nicholas Ventola es director general del mundialmente famoso restaurante Le Corked. Su sistema de información se
desarrolló con el tiempo y, en la actualidad, consta de dos sistemas de cómputo que no se comunican entre sí. Un
sistema se encarga de las reservaciones y mantiene una base de datos de las preferencias de los clientes (gustos y
aversiones), fechas y aniversarios, y demás información. El otro sistema asigna cada grupo de comensales a una mesa en
una noche dada. En su grupo utilice una metodología descendente para identificar los módulos necesarios para realizar
todo lo que Nicholas quiere hacer con sólo un sistema de cómputo, desde hacer reservaciones hasta ordenar comida. Con
base en su propia experiencia, determine qué sistemas son necesarios para operar un establecimiento de cenas de lujo y
después describa los módulos, además de cómo y cuándo los utilizaría.
2. Divida su grupo en dos subgrupos; uno debe entrevistar a los miembros del otro sobre sus experiencias al registrarse en
una clase. Se debe diseñar preguntas para obtener información sobre costumbres, relatos, proverbios y formas artísticas
que ayudarán a documentar el proceso de registro de su escuela.
3. Reúna a su grupo para desarrollar una página Web para un extracto de un manual de FOLKLORE que documente el
proceso de registro para una clase, basado en el FOLKLORE que se utilizó en las entrevistas del proyecto en grupo 2
antes mencionado. Recuerde incluir ejemplos de costumbres, relatos, proverbios y formas artísticas.
BIBLIOGRAFÍA SELECCIONADA
Evans, J. R. y W. M. Lindsay. An Introduction to Six Sigma and Process Improvement. Florence, KY: Cengage Learning,
2004.
Hecht, J. A. “Business Continuity Management”. Communications of the AIS, Vol. 8, artículo 30, 2002.
Juran, J. M. Managerial Breakthrough. Nueva York: McGraw-Hill, 1964.
Kendall, J. E. y K. E. Kendall, “Metaphors and Methodologies: Living Beyond the Systems Machine”, MIS Quarterly, Vol. 17,
Núm. 2, junio de 1993, pp. 149-171.
Kendall, K. E. “Evaluation of a Regional Blood Distribution Information System”. International Journal of Physical Distribu-
tion and Materials Management, Vol. 10, Núm. 7, 1980.
Kendall, K. E., J. E. Kendall y K. C. Lee. “Understanding Disaster Recovery Planning through a Theatre Metaphor: Rehearsing
for a Show That Might Never Open”. Communications of AIS, Vol. 16, 2005, pp. 1001-1012.
Kendall, K. E. y R. Losee, “Information System FOLKLORE: A New Technique for System Documentation”, Information and
Management, Vol. 10, Núm. 2, 1986, pp. 103-111.
Kobieulus, J. “Above the Cloud”, Network World, diciembre 15 de 2008, p. 22. www.networkworld.com. Último acceso en 26
de agosto de 2009.
Stephens, D. O. “Protecting Records in the Face of Chaos, Calamity and Cataclysm”, The Information Management Journal,
enero/febrero de 2003, pp. 33-40.
Warkentin, W., R. S. Morse, E. Bekkering y A. C. Johnston. “Analysis of Systems Development Project Risks: An Integrative
Framework. The DATA BASE for Advances in Information Systems, Volumen 40, Número 2, mayo de 2009, pp. 8-21.
Wikipedia, the free encyclopedia, “Cloud Computing”. Último acceso en 26 de agosto de 2009.
Zmud, R. W. y J. F. Cox, “The Implementation Process: A Change Approach”, MIS Quarterly, Vol. 3, Núm. 2, 1979, pp.
35-44.www.xlibros.com

CAPÍTULO 16 • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD 555
E P I S O D I O 1 6
CASO DE LA CPU
ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL
Semper Redundate
Mack Roe se dirige hacia el escritorio de Anna, donde también se encuentra Chip, y dice: “Se ha probado el último programa
e incorporado a la prueba del sistema. Los resultados indican que el sistema está terminado. Todos los programas y subsistemas
funcionan de la manera como se planeó. Todo el sistema se revisó en detalle. Las pruebas han sido extensas y precisas, y todos
los problemas y errores se han resuelto de manera satisfactoria. He revisado todo lo que se debía entregar, y todo se desarrolló
en los programas. Los dejo que lo instalen y que después celebren”.
“¡Esto es grandioso!”, exclama Anna cuando Mack se aleja. “Hemos estado esperando mucho este momento. Ahora tene-
mos la tarea de instalar el sistema. Ya revisé con Mike Crowe: ya llegó todo el hardware y está instalado. Las computadoras se
conectaron en una configuración de estrella, y ya se instaló el software de red. ¿Por qué no hacemos una lista de las tareas que
debemos realizar?”.
“De acuerdo”, responde Chip. “Tenemos que capacitar a los usuarios en el manejo del sistema. Sería bueno ofrecer primero
una capacitación general, y luego la capacitación específica para cada usuario. Tal vez sea necesario que capacitemos a varias
personas —al usuario y a alguien que lo sustituya— para cada operación específica.”
“Me parece bien”, contesta Anna, “pero no creo que sea conveniente un sustituto para Paige Prynter. No creo que a ella le
agrade la idea”.
“Hablando de sustitución”, agrega Chip, “¿qué hay de la creación de respaldos de las tablas maestras de la base de datos
y otras tablas? Deberíamos diseñar algún procedimiento automatizado para crear estas copias”.
“Sí”, responde Anna. “Excelente idea. También debemos ocuparnos de la seguridad del sistema: quién puede acceder a los
datos, y quién puede actualizar los diversos elementos de la base de datos. También deberíamos crear un plan de recuperación de
desastres, sólo en caso de que ocurran cosas como cortes de energía u otros desastres naturales o provocados por los humanos”.
“De acuerdo”, subraya Chip. “Uno nunca sabe cuando las cosas pueden salir mal. Otro pendiente es convertir al nuevo
formato los archivos de producción del sistema anterior. No necesitamos volver a teclear todos los registros de los archivos
maestros de hardware y software.”
“¿Por qué no encargamos a uno de los programadores que escriba un programa único que convierta al nuevo formato cada
uno de los archivos del formato viejo?”, sugiere Anna. “Los índices se podrían actualizar automáticamente, y los campos adi-
cionales se podrían inicializar con espacios o ceros”.
Los programadores terminan en poco tiempo los programas de conversión de archivos. Las nuevas tablas de la base de
datos se crean y su exactitud se verifica con gran detalle. Este esfuerzo se ve recompensado con nuevas tablas que contienen
todas las filas necesarias con información correcta.
La capacitación se programa para comenzar en el Centro de Información. Hy Perteks tiene mucha disposición para dedicar
tiempo a la instalación del software y a impartir las sesiones de capacitación. Chip y Anna se alternan para dar capacitación en
las respectivas áreas del sistema que crearon.
Al finalizar las sesiones de capacitación, la última tarea consiste en la conversión del sistema viejo al nuevo. Se elige el
método de fases como el mejor enfoque. Primero se instalan los programas en el hardware. Los registros se actualizan con in-
formación para los elementos adicionales que se incluyeron en el diseño del sistema.
A continuación, se instalan los programas de actualización del software. Una vez más, se introducen actualizaciones a las
tablas de las bases de datos. Cuando los registros contienen toda la información necesaria, se instalan las pantallas de consulta.
Por último, se agregan al sistema los programas de informes y menús.
“La instalación es un éxito redondo”, se regocija Chip. “Todo funciona correctamente, sin un error en el sistema. Creo que
deberíamos tocar madera. ¿Te han comentado algo los usuarios?”.
“Sí”, responde Anna. “Están felices y aliviados por contar con su nuevo sistema. Mike Crowe ya empezó a utilizar la ca-
racterística de mantenimiento preventivo, y puso a sus estudiantes a que le ayudaran a realizarlo en un salón de laboratorio a la
vez. Cher y Dot han ejecutado las diversas pantallas y varias veces han elogiado lo fácil que es realizar sus tareas. Visité a Paige
Prynter, y me pidió que le sugiriera qué hacer con todo el tiempo libre que le queda.”
“Entiendo que el sistema Web está disponible a través del portal de maestros. Se enviaron avisos por correo electrónico
sobre la disponibilidad del sistema Web y las sesiones de capacitación”.
Los analistas sonríen. Chip dice: “En realidad ha sido bueno trabajar en este proyecto”.
“Así es”, responde Anna. “El mejor sistema que hemos creado aquí en la CPU.”
“También he aprendido mucho de la universidad en mi breve estancia aquí. Es un buen lugar para trabajar”, dice Chip con
filosofía.
“Y si recuerdas nuestro lema, debes hacerlo bien”, responde Anna. “Semper redundate”, le dice a Chip.
“Sí, lo veo en todos los membretes. Sin embargo, admito que nunca tomé latín en la escuela. ¿Qué significa este lema?”,
pregunta Chip.
“¡Respalda siempre!”, dice Anna con seguridad.www.xlibros.com

556 PARTE V • ASEGURAMIENTO E IMPLEMENTACIÓN DE LA CALIDAD
EJERCICIOS
E-1. Describa los procedimientos que deben diseñarse para crear archivos de respaldo de manera automática. Explique en un
párrafo los pros y contras de estos procedimientos.
E-2. Mencione las medidas de seguridad que deben tomarse para impedir que personas no autorizadas utilicen el sistema de
cómputo.
E-3. Describa un plan de recuperación de desastres para el nuevo sistema de cómputo que acaba de crear para la CPU. Haga
un énfasis especial en los equipos que serán responsables de manejar una crisis.
E-4. Explique en un párrafo por qué se utilizaría una conversión en fases para instalar el sistema de cómputo.www.xlibros.com

557
Los números entre paréntesis hacen referencia al capítulo en
el que se define el término.
ACOPLAMIENTO DE DATOS Representación de la
forma de pasar los datos entre dos módulos en un diagrama
(o gráfico) de estructura. (16)
ACTOR En UML, el rol específico de un usuario del
sistema. El actor existe fuera del sistema e interactúa con el
mismo de una manera específica. Un actor puede ser un
humano, otro sistema o un dispositivo tal como un teclado.
(10) Vea también caso de uso.
ADMINISTRACIÓN DE LA CADENA DE
SUMINISTRO El esfuerzo de una organización por integrar
a sus proveedores, distribuidores y los requerimientos
administrativos de los clientes en un solo proceso unificado.
Las aplicaciones de comercio electrónico pueden mejorar la
administración de la cadena de suministro. (16)
ADMINISTRACIÓN DE PROYECTOS El arte y la
ciencia de planificar un proyecto, estimar costos y
calendarios, administrar el riesgo, organizar y supervisar un
equipo. Existen muchos paquetes de software para apoyar las
tareas de administración de proyectos. (3)
ADMINISTRADOR DE PROYECTOS La persona
responsable de supervisar la planificación, costos,
calendarios y organización del equipo de un proyecto
(a menudo de sistemas). Con frecuencia este papel lo
desempeña un analista de sistemas. (3)
AGREGACIÓN A menudo se describe como relación
“tiene un” al usar UML para una metodología orientada a
objetos. Las agregaciones proveen la manera de mostrar que
un objeto está compuesto en su totalidad por la suma de sus
partes (otros objetos). (10)
AJAX Un método que utiliza JavaScript y XML para
modificar páginas Web en forma dinámica sin tener que
mostrar una nueva página, para lo cual obtiene pequeñas
cantidades de datos del servidor. (12)
AJUSTE Describe la forma en que trabajan en conjunto
los elementos HCI del humano, la computadora y la tarea a
realizar para mejorar el rendimiento y bienestar. (14)
ALIAS Nombre alternativo para un elemento de datos usado
por distintos usuarios. Se registra en un diccionario de datos. (8)
ALMACÉN DE DATOS Datos que se almacenan en el
sistema; se representa mediante un rectángulo con un
extremo abierto en los diagramas de flujo de datos. (7).
ALMACÉN DE DATOS CORPORATIVO Una colección
de datos de apoyo de los procesos de decisión administrativos
que está orientada al tema, integrada, varía con el tiempo y es
no volátil. (14) Vea también minería de datos.
ANÁLISIS DE PUNTOS DE FUNCIÓN Una manera de
estimar el tamaño de un proyecto, tomando en cuenta los
cinco componentes principales de los sistemas
computacionales: entradas externas, salidas externas,
consultas de registros externas, archivos lógicos internos y
archivos de interfaz externa. (3)
ANALISTA DE SISTEMAS La persona que evalúa de
manera sistemática la forma en que funcionan los negocios,
mediante un examen de la introducción y el procesamiento
de los datos y la información de salida con la intención de
mejorar los procesos organizacionales y la calidad de la vida
útil para los usuarios. (1)
ÁRBOL DE DECISIONES Un método de análisis para las
decisiones estructuradas; es una metodología apropiada cuando
es necesario realizar las acciones en cierta secuencia. (9)
ARQUITECTURA CLIENTE/SERVIDOR Un modelo
de diseño en el que las aplicaciones se ejecutan en una red de
área local (LAN). Las computadoras en la red dividen las
tareas de procesamiento entre servidores y clientes. Los
clientes son máquinas en red que actúan como puntos de
entrada en el sistema cliente/servidor. (16)
ARQUITECTURA ORIENTADA A SERVICIOS
(SOA) Crear servicios de software individuales que no estén
asociados o que tengan un acoplamiento débil con algún otro
elemento como aplicaciones o partes de aplicaciones para los
usuarios, usando a menudo la Web como plataforma. (16)
ATRIBUTO Cierta característica de una entidad. Puede
haber muchos atributos para cada entidad. (13) Vea también
elemento de datos.
BANDERA DE CONTROL Se utiliza en los diagramas
(o gráficos) de estructura para gobernar la porción a ejecutar
de un módulo; se asocia con instrucciones IF, THEN, ELSE
y demás tipos similares de instrucciones. (16)
GLOSARIOwww.xlibros.com

558 GLOSARIO
BASE DE DATOS Un almacén de datos electrónico
definido de manera formal y controlado en forma central,
para usarse en muchas aplicaciones. (13)
BENEFICIOS INTANGIBLES Beneficios que se
acumulan en la organización como resultado de un nuevo
sistema de información y que son difíciles de medir, como
mejorar la toma de decisiones, mejorar la precisión y
volverse más competitivo. (3) Vea también costos
intangibles, beneficios tangibles, costos tangibles.
BENEFICIOS TANGIBLES Ventajas que se pueden
medir en dinero y se acumulan en la organización a través
del uso de los sistemas de información. (3) Vea también
beneficios intangibles, costos intangibles, costos tangibles.
BOTÓN DE OPCIÓN Uno de varios elementos de
diseño de GUI que provee un botón de opción redondo en
un cuadro de diálogo. Los botones son mutuamente
excluyentes, debido a que un usuario puede escoger sólo un
botón de opción dentro del grupo de opciones que se
visualicen. (11)
CAMPO Una parte física de una base de datos que se
puede empaquetar con varios elementos de datos; la unidad
más pequeña identificable de datos de la aplicación,
reconocida por el software del sistema. (13)
CARRILES (SWIMLANES) Zonas que se utilizan en los
diagramas de actividad para indicar el particionamiento;
pueden mostrar qué actividades se realizan en cada
plataforma y qué grupo de usuarios las realiza; también
pueden representar la lógica del sistema. (10)
CASO DE USO En UML, una secuencia de transacciones
en un sistema; el propósito es producir algo de valor para un
actor en el sistema; se concentra en lo que hace el sistema,
en vez de en cómo lo hace. El modelo de caso de uso se basa en
las interacciones y relaciones de casos de uso individuales.
En un caso de uso, un actor que utiliza el sistema inicia un
evento que a su vez empieza una serie relacionada de
interacciones en el sistema. (10)
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
(SDLC) Una metodología de siete fases para el análisis y
diseño de sistemas, la cual sostiene que los sistemas se
desarrollan mejor mediante el uso de un ciclo específico de
actividades de analistas y usuarios. (1)
CIFRADO El proceso de hacer ilegible un mensaje
mediante el uso de una clave, de manera que pueda leerlo
sólo el destinatario designado. De esta forma, la persona
designada como receptor del mensaje puede utilizar la clave
para descifrarlo y leerlo. (13)
CLASE Una plantilla común para un grupo de objetos
individuales con atributos y comportamientos comunes en el
análisis y diseño orientados a objetos, y en el UML. (10)
CLASE DE OBJETO Una categoría de objetos similares.
Los objetos se agrupan en clases. Una clase define el
conjunto de atributos y comportamientos compartidos que se
encuentran en cada objeto de la clase. (10)
CLAVE (O LLAVE) Uno de los elementos de datos en un
registro que se utiliza para identificar al registro. (13) Vea
también clave primaria, clave secundaria.
CLAVE (O LLAVE) CONCATENADA Una clave
compuesta que se crea cuando no es posible identificar un
registro con sólo utilizar uno de los elementos de datos que
se encuentran en él; para elegir una clave se elijen dos o
más elementos de datos y se combinan entre sí. (13)
CLAVE (O LLAVE) PRIMARIA Una clave que
identifica a un registro en forma única. (13) Vea también
clave, clave secundaria.
CLAVE (O LLAVE) SECUNDARIA Una clave que no
puede identificar a un registro en forma única; se puede
utilizar para seleccionar un grupo de registros que
pertenezcan a un conjunto. (13)
CÓDIGO NEMÓNICO Cualquier código (a menudo
utilizando una combinación de letras y símbolos) que ayuda
al capturista de datos a recordar cómo introducirlos
correctamente, o que ayuda al usuario a recordar cómo usar
la información. (15)
COMERCIO ELECTRÓNICO Hacer negocios por vía
electrónica, incluyendo el correo electrónico, las tecnologías
Web, BBS, tarjetas inteligentes, EFT y EDI, entre
proveedores, clientes, agencias gubernamentales y otras
empresas para realizar y ejecutar transacciones en
actividades comerciales, administrativas y de los
consumidores. (1)
COMPLEMENTO (PLUG-IN) Software adicional
(a menudo desarrollado por un tercero) que se puede utilizar
con otro programa; por ejemplo, los complementos Real
Player de RealNetworks o Flash de Macromedia se utilizan
en los navegadores Web para reproducir audio o video de
flujo continuo y ver animaciones basadas en vectores. (11)
COMPORTAMIENTO La forma en que un objeto actúa
y reacciona. (10)
CÓMPUTO EN LA NUBE Esquema dentro del cual las
organizaciones y los usuarios individuales utilizan servicios
Web, de bases de datos y de aplicaciones a través de
Internet (la nube), sin tener que invertir en hardware
o software corporativo o personal, o en herramientas de
software adicionales a las que la Web proporciona. Las
empresas utilizan navegadores Web para acceder a las
aplicaciones y los servidores almacenan software y datos
para las empresas. (16)
CONSULTAS Preguntas que los usuarios hacen a la base
de datos en relación con la información que contiene. Cada
consulta involucra a una entidad, un atributo y un valor. (14)
CONVERSIÓN Convertir físicamente la información del
sistema antiguo al nuevo sistema. Hay cinco estrategias de
conversión: cambio directo, conversión en paralelo, conversión
en fases o gradual, conversión de prototipo modular y
conversión distribuida.
COSAS En UML, las cosas describen a los objetos del
análisis y diseño orientados a objetos. Los dos agrupamientos
de cosas que se utilizan con más frecuencia son las cosas
estructurales y las cosas de comportamiento. (10)
COSTOS INTANGIBLES Costos que son difíciles de
estimar y que tal vez se desconozcan, incluyendo el perder la
ventaja competitiva o la reputación de innovador, y deteriorarwww.xlibros.com

GLOSARIO 559
la imagen de la empresa debido a información inoportuna o
inaccesible. (3) Vea también beneficios intangibles,
beneficios tangibles, costos tangibles.
COSTOS TANGIBLES Los costos en dinero que el analista
de sistemas puede pronosticar con precisión, incluyendo el
costo de las computadoras, los recursos, el tiempo de los
analistas y programadores, y los salarios de los demás
empleados, para desarrollar un nuevo sistema. (3) Vea también
beneficios intangibles, costos intangibles, beneficios tangibles.
CREACIÓN DE PROTOTIPOS Un proceso rápido e
interactivo entre los usuarios y analistas para crear y refinar
porciones de un nuevo sistema; se puede utilizar como parte
del ciclo de vida del desarrollo de sistemas (SDLC) para
determinar los requerimientos, o como una alternativa para el
SDLC. (6) Vea también desarrollo rápido de aplicaciones.
DEFINICIÓN DEL PROBLEMA Una declaración formal
del problema, incluyendo: 1) aspectos de la situación actual,
2) los objetivos para cada cuestión, 3) los requerimientos que
se deben incluir en todos los sistemas propuestos y 4) las
restricciones que limitan el desarrollo del sistema. (3)
DESARROLLO RÁPIDO DE APLICACIONES
(RAD) Una metodología orientada a objetos para el
desarrollo de sistemas, la cual incluye un método de
desarrollo junto con herramientas de software. (6) Vea
también creación de prototipos.
DESNORMALIZACIÓN
(O DENORMALIZACIÓN) Definir registros físicos que no
estén en la tercera forma normal o en una superior; incluye la
unión de atributos de varias relaciones entre sí para evitar el
costo de acceder a varios archivos. El particionamiento es
una forma intencional de desnormalización. (13)
DIAGRAMA DE BURBUJA Un diagrama simple que
muestra las asociaciones de datos de los elementos de datos.
Cada entidad se encierra en una elipse y se utilizan flechas
para mostrar las relaciones. También se le conoce como
diagrama de modelo de datos. (13)
DIAGRAMA DE CLASES Se usa para modelar en forma
gráfica la vista de diseño estructural estática de un sistema;
ilustra los requerimientos funcionales del sistema recopilados
mediante el análisis, así como el diseño físico del sistema. (10)
DIAGRAMA DE ESTADOS En UML, una forma de
refinar aún más los requerimientos. (10)
DIAGRAMA DE ESTRUCTURA Una herramienta para
diseñar un sistema modular arriba-abajo, la cual consiste en
cuadros rectangulares y flechas de conexión. (16) Vea
también bandera de control, acoplamiento de datos.
DIAGRAMA DE FLUJO DE DATOS
(DFD) Representación gráfica de los procesos de datos,
flujos de datos y almacenes de datos en un sistema
comercial. (7)
DIAGRAMA DE FLUJO DE DATOS A NIVEL DE
CONTEXTO El diagrama de flujo de datos más básico de
una organización; muestra la forma en que los procesos
transforman los datos entrantes en información saliente.
También se le conoce como modelo ambiental. (2) Vea
también diagrama de flujo de datos.
DIAGRAMA DE FLUJO DE DATOS FÍSICO Un DFD
que muestra la forma en que se implementará un sistema,
incluyendo el hardware, software, las personas y los
archivos involucrados. (7) Vea también diagrama de flujo
de datos lógico.
DIAGRAMA DE FLUJO DE DATOS LÓGICO Un
diagrama que se enfoca en el negocio y la manera en que éste
opera; describe los eventos de negocios que se llevan a cabo
y los datos que cada evento requiere y produce. (7) Vea
también diagrama de flujo de datos, diagrama de flujo de
datos físico.
DIAGRAMA DE NIVEL 0 La expansión
(o descomposición) del diagrama de flujo de datos a nivel de
contexto, que muestra de tres a nueve procesos importantes,
flujos de datos importantes y almacenes de datos del sistema
que se está estudiando. (7)
DIAGRAMA DE OBJETOS Un diagrama similar a los
diagramas de clase, pero que representa el estado de las
instancias de la clase y sus relaciones en un punto en el
tiempo; muestra los objetos y sus relaciones. También
muestra la opcionalidad (el cliente puede tener cero o más
contratos de renta) y la cardinalidad (el contrato de renta sólo
puede tener un cliente). (10)
DIAGRAMA DE SECUENCIA En UML, un diagrama
de secuencia ilustra una sucesión de interacciones entre
instancias de objetos a través del tiempo. A menudo se utiliza
para ilustrar el procesamiento descrito en escenarios de casos
de uso. (10)
DIAGRAMA ENTIDAD-RELACIÓN (E-R) Una
representación gráfica de un modelo E-R. (8)
DIAGRAMA HIJO El diagrama que resulta al expandir un
proceso del Diagrama 0 (conocido como proceso padre). (7)
DIAGRAMA PERT Una herramienta que se utiliza para
determinar las actividades críticas de un proyecto. Se puede
utilizar para mejorar la calendarización de un proyecto y
evaluar su progreso. Significa Técnica de Revisión y
Evaluación de Programas. (3)
DICCIONARIO DE DATOS Una obra de consulta con
información sobre los datos (metadatos) creados por el
analista de sistemas con base en los diagramas de flujo de
datos; recopila y coordina términos de datos específicos,
confirmando lo que cada término significa para distintas
personas en la organización. (8)
DIRECCIÓN IP (PROTOCOLO DE INTERNET) El
número que se utiliza para representar una computadora
individual en una red. El formato para una dirección IP es
999.999.999.999. (16)
DISEÑO DE APLICACIÓN CONJUNTA (JAD) La
metodología propietaria de IBM para las entrevistas de panel
con analistas, usuarios y ejecutivos para realizar el análisis
de requerimientos en forma conjunta. (4)
DOCUMENTACIÓN Material escrito creado por el
analista que describe la forma de ejecutar el software,
muestra las generalidades del sistema o detalla el código del
programa utilizado. Los analistas pueden utilizar una
herramienta CASE para facilitar la documentación. (16)www.xlibros.com

560 GLOSARIO
ELEMENTO DE DATOS La unidad más pequeña de un
archivo o base de datos. Se utiliza como sinónimo de la
palabra atributo. (13)
ELEMENTO DE INFORMACIÓN Una simple pieza de
datos, puede ser de base o derivado; se debe definir en el
diccionario de datos. (8).
ENCAPSULAMIENTO En el análisis y diseño orientados
a objetos, un objeto está encapsulado por su comportamiento.
Un objeto mantiene información sobre las cosas del mundo
real que representa en sentido verdadero. A un objeto se le
debe pedir o indicar que modifique su propia información
mediante un mensaje. (10)
ENTIDAD Persona, grupo, departamento o sistema que
recibe o crea información o datos. Uno de los símbolos
primarios en un diagrama de flujo de datos. (2) Vea también
diagrama de flujo de datos, entidad externa.
ENTIDAD ASOCIATIVA Un tipo de entidad que asocia
las instancias de uno o más tipos de entidades y contiene
atributos peculiares para la relación entre esas instancias de
entidades. (2)
ENTIDAD ATRIBUTIVA Uno de los tipos de entidades
que se utilizan en los diagramas entidad-relación. Es útil para
describir atributos, en especial los grupos repetitivos. (2)
ENTIDAD EXTERNA Un origen o destino de datos que
se considera externo para el sistema que se está describiendo.
También se le conoce como entidad. (7) Vea también
diagrama de flujo de datos.
ENTORNO Cualquier cosa externa a una organización.
Existen varios entornos, como el físico, económico, legal y
los entornos sociales. (2)
ENTRADA Cualquier dato, ya sea texto o números, que se
introduce en un sistema de información para fines de
almacenamiento o procesamiento mediante formularios,
pantallas, voz o formularios de llenado interactivos basados
en Web. (12).
ENTREGABLES El software, la documentación, los
procedimientos, los manuales de usuario o las sesiones de
capacitación que un analista de sistemas entrega a un cliente
con base en promesas contractuales específicas. (3)
ESPAÑOL ESTRUCTURADO Una técnica para analizar
las decisiones estructuradas con base en la lógica de la
estructura e instrucciones en lenguaje simple, como sumar,
multiplicar y mover. (9)
ESQUEMAS DE XML Una forma precisa de definir
el contenido de un documento de XML; puede incluir el
número exacto de veces que puede ocurrir un elemento,
el tipo de datos dentro de los elementos, los límites sobre los
datos y el número de posiciones a la izquierda y derecha de
un número decimal. (8)
ESTATUTOS DEL PROYECTO Un documento que
describe los resultados esperados del proyecto de sistemas
(entregables) y el periodo de tiempo para la entrega; en
esencia se convierte en un contrato entre el analista en jefe
(o administrador del proyecto) y su equipo de análisis con
los usuarios de la organización que solicitan el nuevo
sistema. (3)
ESTRUCTURA DE DATOS Estructuras compuestas de
elementos de información; por lo general se describen
mediante el uso de notación algebraica para producir una
vista de los elementos. El analista empieza con el diseño
lógico y después diseña las estructuras de datos físicas. (8)
FACILIDAD DE USO La forma que tienen los
diseñadores de evaluar los sistemas e interfaces que crean
con vista a considerar todas las cuestiones de HCI que
puedan con el mayor detalle posible. (14)
FASE DE EXPLORACIÓN Es la fase inicial del
desarrollo ágil en donde el analista evalúa su convicción de
que la metodología ágil es la correcta, después ensambla el
equipo de desarrollo y evalúa sus habilidades. Puede durar
unas cuantas semanas o unos cuantos meses. (1)
FASE DE PUESTA EN PRODUCCIÓN La fase en el
desarrollo ágil cuando se libera el software y se recibe la
retroalimentación para mejorar el producto de software. El
proceso de liberar las versiones del producto se puede llevar
a cabo con una frecuencia incluso semanal. (1)
FAVICON Un pequeño icono que aparece a un lado de
cualquier dirección marcada como favorita en un navegador.
Al copiar el vínculo marcado como favorito al escritorio se
obtiene una versión más grande del icono y se copia ahí. Se
pueden generar favicons únicos mediante un generador de
iconos de Java u otros programas de gráficos. (11)
FIREWALL Software de seguridad computacional que se
utiliza para erigir una barrera entre la LAN de una
organización e Internet. Aunque evita que los hackers entren
a una red interna, también evita que los miembros de la
organización obtengan el acceso directo a Internet. (16)
FLUJO DE DATOS Datos que se mueven en el sistema de
un lugar a otro; la entrada y la salida se representan mediante
el uso de una flecha con punta en los diagramas de flujo de
datos. (7)
FOLKLORE Una técnica de documentación de sistemas
basada en los métodos tradicionales que se utilizan para
recopilar información sobre las personas y las leyendas. (16)
GRÁFICO DE GANTT La representación gráfica de un
proyecto que muestra la actividad de cada tarea como una
barra horizontal, cuya longitud es proporcional al tiempo en
el que se va a completar. (3)
GRUPO REPETITIVO La existencia de muchos de los
mismos elementos en una estructura de datos. (8) Vea
también estructura de datos.
HERENCIA En el análisis y el diseño orientados a objetos,
las clases pueden tener hijos. La clase padre se conoce como
la clase base, y la clase hijo se conoce como clase derivada. La
clase derivada se puede crear de manera que herede todos los
atributos y comportamientos de la clase base. (10)
HERRAMIENTAS CASE Herramientas de ingeniería de
software apoyada por computadoras que incluyen la
capacidad de crear diagramas, análisis y modelado
automatizados basados en computadora. (1)
HERRAMIENTAS CASE DE BAJO
NIVEL Herramientas CASE utilizadas por los analistas
para generar código fuente de computadora, con lo cualwww.xlibros.com

GLOSARIO 561
eliminan la necesidad de programar el sistema. (1) Vea
también herramientas CASE.
HIPERVÍNCULO Cualquier palabra resaltada en un
sistema de hipertexto que muestra otro documento cuando el
usuario hace clic en ella. (11)
ICONO Pequeña imagen que representa una actividad y
función, u otro elemento de un sistema operativo como un
archivo o un directorio, disponible para los usuarios cuando
la activen, a menudo mediante un clic del ratón. Se usa con
frecuencia en el diseño de GUI. (14)
IMPLEMENTACIÓN La última fase del ciclo de vida del
desarrollo de sistemas, en la cual el analista asegura que el
sistema está en operación y después permite a los usuarios
hacerse cargo de su operación y evaluación. (16)
INGENIERÍA DE SOFTWARE APOYADA POR
COMPUTADORA (CASE) Herramientas de software
especializadas que incluyen capacidades de diagramación,
análisis y modelado automatizados basados en computadora. (1)
INTERACCIÓN HUMANO-COMPUTADORA
(HCI) El aspecto que permite la comunicación y las
interacciones entre los humanos y la computadora; la capa de
la computadora entre los humanos y la computadora. (14)
INTERFAZ DE LENGUAJE DE COMANDOS Un tipo
de interfaz que permite a los usuarios controlar la aplicación
con una serie de pulsaciones de teclas, comandos, frases o
alguna combinación de estos métodos. (14)
INTERFAZ DE LENGUAJE NATURAL Una interfaz
que permite al usuario hablar o escribir en un lenguaje
humano para interactuar con la computadora. (14)
INTERFAZ DE LLENADO DE FORMULARIOS Parte
de los elementos de diseño de GUI que pide de manera
automática al usuario que llene un formulario estándar. Es
útil para las aplicaciones de comercio electrónico. (14)
INTERFAZ GRÁFICA DE USUARIO (GUI) Una
interfaz de usuario basada en iconos, con características
como menús y listas desplegables, y botones de opción. (14)
JAVA Un lenguaje de programación orientado a objetos
que permite ejecutar aplicaciones dinámicas en Internet. (11)
JUEGO DE PLANEACIÓN Se utiliza en el desarrollo
ágil; el juego de planeación establece las reglas que pueden
ayudar a formular la relación del equipo de desarrollo ágil
con sus clientes comerciales. (1)
LENGUAJE UNIFICADO DE MODELADO (UML) El
UML provee un conjunto estandarizado de herramientas para
documentar el análisis y diseño orientados a objetos de un
sistema de software. (10)
LÍNEA DE SUSCRIPTOR DIGITAL (DSL) Protocolos
que permiten la transmisión de datos de alta velocidad a
través del cable telefónico común. (16)
LISTA DESPLEGABLE Uno de varios elementos de
diseño de GUI que permite a los usuarios hacer clic en un
cuadro que parece desplegarse en la pantalla y muestra una
lista de alternativas, de las cuales se puede elegir una. (11)
MANTENIMIENTO El mantenimiento dado al sistema
de información para mejorarlo o corregir problemas empieza
en esta fase del SDLC y continúa durante la vida del sistema.
Cierta parte del mantenimiento se puede realizar de manera
automática al conectarse al sitio Web del distribuidor. (1)
MASHUPS Una nueva aplicación que se crea al combinar
dos o más API (interfaces de programación de aplicaciones)
basadas en Web.
MENÚ DESPLEGABLE Uno de varios elementos de
diseño de GUI que provee un menú en pantalla de opciones
de comandos que aparecen una vez que el usuario selecciona
el nombre del comando en una barra de menús. (14) Vea
también lista desplegable.
MÉTODO En UML, una acción que se puede solicitar de
cualquier objeto de la clase; los procesos que una clase sabe
cómo realizar. (10)
METODOLOGÍA ÁGIL (O MODELADO ÁGIL) Una
metodología de desarrollo de sistemas que tiene valores,
principios y prácticas útiles para los analistas de sistemas que
desean una metodología flexible, interactiva y participativa.
(6) Vea también programación extrema.
METODOLOGÍA DE DESARROLLO DE
SISTEMAS Cualquier metodología aceptada para analizar,
diseñar, implementar, probar, mantener y evaluar un sistema
de información. Algunos ejemplos de metodologías son:
SDLC, metodologías ágiles, y el análisis y diseño de
sistemas orientados a objetos. (1) Vea también ciclo de vida
del desarrollo de sistemas.
MINERÍA DE DATOS Técnicas que aplican algoritmos
para extraer patrones de datos guardados en almacenes de
datos corporativos que por lo general no son aparentes para los
humanos que toman las decisiones. También se le conoce
como descubrimiento de conocimiento en bases de datos
(KDD). (14)
MODELO DE ACEPTACIÓN DE TECNOLOGÍA
(TAM) Un método basado en la investigación que permite
a los analistas organizar su modo de pensar en cuanto a si los
usuarios aceptarán y utilizarán la tecnología de información,
incluyendo la utilidad y la facilidad de uso percibidas. (14)
MODELO DE BASE DE DATOS
RELACIONAL Representa a los datos en la base de datos
como tablas bidimensionales llamadas relaciones. Mientras
que ambas tablas compartan un elemento de datos común, la
base de datos podrá relacionar cualquier otro archivo o tabla
con los datos en otro archivo o tabla. (13)
MUESTREO Seleccionar de manera sistemática elementos
representativos de una población. Los analistas muestrean los
datos concretos, los datos de archivo y las personas durante la
determinación de los requerimientos de información. (5)
NAVEGADOR Software especial que se ejecuta en
computadoras conectadas a Internet y permite a los usuarios
ver páginas Web de hipertexto en Internet. Microsoft Internet
Explorer y Mozilla Firefox son ejemplos de navegadores
gráficos. (11)
NORMALIZACIÓN La transformación de los almacenes
de datos y vistas de usuario complejas en un conjunto de
estructuras de datos más pequeñas y estables. Las estructuras
de datos normalizadas se pueden mantener con más facilidad
que las estructuras complejas. (13)www.xlibros.com

562 GLOSARIO
OBJETO En la metodología orientada a objetos, un objeto
es una representación computacional de alguna cosa o evento
del mundo real; puede tener tanto atributos como
comportamientos. (10)
OBSERVACIÓN ESTRUCTURADA DEL ENTORNO
(ESTROBO) Un método de observación sistemática para
clasificar e interpretar elementos organizacionales que
influyen en la toma de decisiones. Se basa en la técnica de
crítica de cine conocida como mise-en-scéne. (5)
ORGANIZACIÓN DE ARCHIVOS INDEXADOS Un
tipo de organización de archivos que utiliza archivos índice
separados para localizar los registros. (13)
PANTALLA Cualquiera de una variedad de alternativas de
visualización que emplean los usuarios para ver el software
de computadora, incluyendo los monitores y las pantallas de
plasma o de cristal líquido. (11)
PAQUETE En UML las cosas se pueden agrupar en
paquetes, a los cuales se les puede considerar como
subsistemas físicos. Los sistemas se implementan y
despliegan en paquetes. (10)
PEGAJOSIDAD Una propiedad de las páginas Web,
utilizada especialmente en el comercio electrónico. Las
herramientas que incrementan la pegajosidad de una
página Web son aquellas que alientan a los clientes a
permanecer más tiempo en la página, los ayudan a
navegar de vuelta a la página si hacen clic en un vínculo e
incrementan la probabilidad de que completen una
compra. (14)
PENSAMIENTO EN OBJETOS Instrucciones
elementales que el analista escribe en tarjetas CRC para
empezar a pensar en una forma orientada a objetos. (10)
PLANIFICACIÓN DE RECUPERACIÓN DE
DESASTRES Planes estratégicos y tácticos para ayudar a
las personas y los sistemas a recuperarse en caso de desastres
naturales y provocados por los humanos. (16)
PODCASTING La técnica de colocar archivos de audio
descargables en la Web. (11)
POLIMORFISMO Comportamientos alternativos entre
las clases derivadas en las metodologías orientadas a objetos.
Cuando varias clases heredan tanto atributos como
comportamientos, el comportamiento de una clase derivada
podría ser distinto al de su clase base o al de sus clases
derivadas hermanas. (10)
PREGUNTA ABIERTA Un tipo de pregunta que se utiliza
en entrevistas o encuestas y que abre el posible conjunto de
respuestas disponibles para los que responden a las
preguntas. (4) Vea también pregunta binaria, pregunta
cerrada.
PREGUNTA BINARIA Un subconjunto de preguntas
cerradas que se pueden responder sólo de dos formas: sí o
no, verdadero o falso, y de acuerdo o en desacuerdo. (4) Vea
también pregunta cerrada, pregunta abierta.
PREGUNTA CERRADA Un tipo de pregunta que se
utiliza en entrevistas o encuestas y que limita el conjunto de
respuestas disponibles para quienes responden a las preguntas.
(4) Vea también pregunta binaria, pregunta abierta.
PRIMERA FORMA NORMAL (1NF) El primer paso
para normalizar una relación en los datos que se utilizan en
una base de datos, de manera que no contenga grupos
repetitivos. (13) Vea también segunda forma normal, tercera
forma normal.
PROCESO Las actividades que transforman o modifican
los datos en un sistema de información. Pueden ser manuales
o automatizadas. Se representan mediante un rectángulo
redondeado en un diagrama de flujo de datos. (2)
PROGRAMACIÓN EN PAREJA Una práctica básica de
la metodología ágil, en la que dos programadores eligen
trabajar juntos en la programación, las pruebas y hablan entre
sí sobre las formas de realizar el trabajo con eficiencia y
efectividad. (6)
PROGRAMACIÓN EXTREMA (XP) La programación
extrema (XP) es una metodología de desarrollo de sistemas
que acepta lo que conocemos como buenas prácticas de
desarrollo de sistemas y las lleva a los extremos. Es el
génesis de las metodologías ágiles. (3)
PRONÓSTICO Los analistas de sistemas tienen que
predecir ciertas variables clave antes de enviar la propuesta
del sistema al cliente. El pronóstico es el arte y la ciencia de
predecir las variables clave, que a menudo se apoya en los
modelos matemáticos de pronóstico. (3)
PROPUESTA DE SISTEMAS Una propuesta escrita que
sintetiza el trabajo del analista de sistemas en el negocio
hasta ese punto, e incluye recomendaciones y alternativas
para resolver los problemas de sistemas identificados. (3)
PROVEEDOR DE SERVICIOS DE APLICACIÓN
(ASP) Una empresa que hospeda software de aplicación y
lo renta a otras empresas para usarlo en la Web. Se incluyen
las aplicaciones tradicionales así como las de colaboración y
administración de datos. (16)
PROVEEDOR DE SERVICIOS DE INTERNET
(ISP) Una empresa que provee acceso a Internet y que
puede proveer otros servicios, como el hospedaje Web y el
análisis del tráfico Web, por un costo. (12)
PRUEBA DE SISTEMAS La sexta fase en el SDLC
(junto con el mantenimiento). Usa tanto los datos de prueba
como los datos en vivo en un momento dado para medir los
errores, la oportunidad de la respuesta, la facilidad de uso, el
orden apropiado de las transacciones, el tiempo inactivo
aceptable, la comprensión de los manuales de procedimientos
y demás aspectos del nuevo sistema. (16)
RECORRIDO ESTRUCTURADO Una revisión
sistemática realizada por expertos en relación con la
programación y el desarrollo del sistema en general, para
resaltar los problemas y permitir que el programador o
analista realice las modificaciones apropiadas. (16)
RED DE ÁREA LOCAL (LAN) El cableado, hardware y
software utilizados para conectar estaciones de trabajo,
computadoras y servidores ubicados en un área geográfica
confinada (por lo general dentro de un edificio o campus). (15)
RED DIGITAL DE SERVICIOS INTEGRADOS
(ISDN) Un servicio de red conmutada que provee
conectividad digital de un extremo a otro para transmitir voz,www.xlibros.com

GLOSARIO 563
datos y video en forma simultánea a través de una sola línea
en vez de a través de varias. (16)
REGISTRO Una colección de elementos de datos que
tienen algo en común con la entidad descrita. (13)
REGLAS DE NEGOCIO Instrucciones específicas para
el funcionamiento de una organización, que proveen la
descripción lógica de las actividades de negocios. Se utilizan
para ayudar a crear diagramas de flujo de datos. (7)
RELACIÓN Asociación entre entidades (algunas veces se
le conoce como asociación de datos); puede tomar la forma
de uno a uno, de uno a varios, de varios a uno o de varios a
varios. (13).
REPOSITORIO DE DATOS Una base de datos centralizada
que contiene todos los diagramas, definiciones de formularios e
informes, estructuras de datos, definiciones de datos, flujos y
lógicas de los procesos, y definiciones de otros componentes
de la organización y del sistema; provee un conjunto de
mecanismos y estructuras para lograr la integración uniforme
de datos con herramientas y de datos con datos. (8)
RUBY ON RAILS Una combinación de lenguaje de
programación y generador de código para crear aplicaciones
Web. (11)
RUTA CRÍTICA La ruta más larga calculada mediante la
técnica de programación PERT; la ruta que provocará el
atraso de todo el proyecto de sistemas si ocurre inclusive un
solo día de retraso . (3)
SALIDA Información que se entrega a los usuarios a
través del sistema de información mediante intranets,
extranets o la Web, en informes impresos, en pantallas o a
través de audio. (11)
SEGUNDA FORMA NORMAL (2NF) Al normalizar los
datos para una base de datos, el analista se asegura de que
todos los atributos que no sean claves dependan por completo
de la clave primaria. Se eliminan todas las dependencias
parciales y se colocan en otra relación. (13) Vea también
primera forma normal, tercera forma normal.
SEIS SIGMA (SIX SIGMA) Una cultura basada en la
calidad; el objetivo es eliminar todos los defectos. (16)
SEUDOCÓDIGO Una técnica para crear instrucciones de
computadora que representan el paso intermedio entre el
lenguaje natural y el código del programa; se utiliza para
representar la lógica de cada módulo en un diagrama de
estructura. (16) Vea también diagrama de estructura.
SISTEMA Una colección de subsistemas que están
interrelacionados y son interdependientes; trabajan en
conjunto para lograr metas y objetivos predeterminados.
Todos los sistemas tienen entrada, procesos, salida y
retroalimentación. Algunos ejemplos son un sistema de
información computarizado y una organización. (2) Vea
también sistema cerrado, sistema abierto.
SISTEMA ABIERTO Parte de la teoría general de
sistemas; un sistema que recibe libremente información,
energía, personas o material prima como entrada. Los sistemas
nunca son totalmente cerrados o totalmente abiertos, sino que
existen en un continuo desde el más cerrado hasta el más
abierto. (2) Vea también sistema cerrado.
SISTEMA CERRADO Parte de la teoría general de
sistemas; un sistema que no recibe información, energía,
personas o materias primas como entrada. Los sistemas
nunca son totalmente cerrados o totalmente abiertos, sino
que existen en un continuo desde el más cerrado hasta el más
abierto. (2) Vea también sistema abierto.
SISTEMA DE ADMINISTRACIÓN DE BASES DE
DATOS (DBMS) Software que organiza los datos en una
base de datos; provee la capacidad de almacenamiento,
organización y recuperación de los datos. (13)
SISTEMA DE INFORMACIÓN GERENCIAL
(MIS) Un sistema de computación compuesto por
personas, software, hardware y procedimientos que
comparten una base de datos común para ayudar a los
usuarios a interpretar y aplicar los datos en el negocio. (1)
SISTEMA DE PROCESAMIENTO DE
TRANSACCIONES (TPS) Un sistema de información
computarizado desarrollado para procesar grandes cantidades
de datos para transacciones de negocios rutinarias, como
nóminas e inventario. (1)
SISTEMA DE SOPORTE DE DECISIONES (DSS) Un
sistema de información interactivo que brinda soporte al
proceso de toma de decisiones a través de la presentación de
información diseñada de manera específica para la
metodología de solución de problemas de la persona que
toma las decisiones y las necesidades de la aplicación. No
toma la decisión en lugar del usuario. (1)
SISTEMA DE SOPORTE PARA EJECUTIVOS
(ESS) Un sistema computacional que ayuda a los
ejecutivos a organizar sus interacciones con el entorno
externo al proveer soporte gráfico y de comunicaciones. (1)
SISTEMA EXPERTO (ES) Un sistema de computadora
que captura y utiliza el conocimiento de un experto para
resolver un problema específico. Los componentes básicos
son la base del conocimiento, un motor de inferencia y la
interfaz de usuario. (1)
SISTEMAS DISTRIBUIDOS Sistemas computacionales
que están distribuidos en forma geográfica, además de que
su procesamiento, datos y bases de datos están distribuidos.
Una arquitectura común para los sistemas distribuidos es el
sistema cliente/servidor basado en LAN. (16)
SISTEMAS EMPRESARIALES Sistemas de
información que se integran a nivel de la organización (en
toda la empresa) y que ayudan a las compañías a coordinar
los procesos organizacionales críticos. (1)
SOFTWARE A LA MEDIDA Otro término para el software
personalizado; es lo opuesto del software comercial para venta
en los canales de distribución tradicionales (COTS). Es
software desarrollado para desempeñar una función específica,
o dar soporte a una característica única de la organización. (1)
SOFTWARE DE CÓDIGO FUENTE ABIERTO
(OSS) Modelo y filosofía de desarrollo en relación con la
distribución de software de una manera libre y publicando su
código fuente, para que los usuarios y programadores puedan
estudiarlo, compartirlo y modificarlo. El sistema operativo
Linux es un ejemplo. (1)www.xlibros.com

564 GLOSARIO
SOFTWARE DE VALIDACIÓN Software que revisa si
los datos introducidos en el sistema de información son
válidos. Aunque la mayor parte de la validación de las
entradas que se realiza a través de software es
responsabilidad del programador, el analista debe saber qué
problemas comunes podrían invalidar una transacción. (15)
SONDEO Preguntas de seguimiento que se utilizan
principalmente durante las entrevistas entre los analistas y
los usuarios. (4) Vea también pregunta cerrada, pregunta
abierta.
TABLA DE DECISIONES Una forma de examinar,
describir y documentar las decisiones estructuradas. Se
dibujan cuatro cuadrantes para describir las condiciones,
identificar las alternativas posibles de decisión, indicar las
acciones que se deben realizar y describir esas acciones. (9)
TABLERO DE CONTROL Visualizador para los que
toman decisiones; incluye una variedad de visualizadores de
medidas de desempeño (o rendimiento) relevantes. (11)
TARJETAS CRC El analista crea tarjetas de Clases,
Responsabilidades y Colaboradores para representar las
responsabilidades de las clases y la interacción entre éstas
cuando se empieza a modelar el sistema desde una
perspectiva orientada a objetos. Los analistas crean las
tarjetas con base en los escenarios que resumen los
requerimientos del sistema. (10)
TERCERA FORMA NORMAL (3NF) Una forma en la
que se eliminan todas las dependencias transitivas. Una
dependencia transitiva es en la que los atributos que no son
clave dependen de otros atributos que tampoco son clave.
(13) Vea también primera forma normal, segunda forma
normal.
TIPO DE ENTIDAD Una colección de entidades que
comparten propiedades o características comunes. (8)
USUARIOS FINALES En una organización, los que no
son profesionales de sistemas de información, que
especifican los requerimientos de negocios para las
aplicaciones de software y las utilizan. A menudo, los
usuarios finales solicitan aplicaciones nuevas o modificadas,
evalúan y aprueban las aplicaciones, y pueden servir en los
equipos de proyectos como expertos de negocios. (1)
VALOR PREDETERMINADO Un valor que asumirá un
campo, a menos que se introduzca un valor explícito en éste.
(13)
VALOR PRESENTE La cantidad total que vale una serie
de pagos a futuro en la actualidad; una forma de evaluar los
desembolsos económicos e ingresos del sistema de
información durante su vida económica, y de comparar los
costos hoy en día con los beneficios a futuro. (10)
VOZ SOBRE PROTOCOLO DE INTERNET (VoIP) El
enrutamiento de los datos de voz a través de Internet. (15)
WEBMASTER La persona responsable de actualizar y dar
mantenimiento a un sitio Web; comúnmente, al principio es
el analista de sistemas durante el desarrollo de las
aplicaciones de comercio electrónico. (12)
XP Vea metodología ágil y programación extrema. (6)www.xlibros.com

ACRÓNIMOS
565
1NF Primera forma normal
2NF Segunda forma normal
3NF Tercera forma normal
AJAX Java Script asíncrono y XML
API Interfaz de programación de aplicaciones
ASP Proveedor de servicios de aplicaciones
B2B Negocio a negocio
B2C Negocio a consumidor
CARE Reingeniería asistida por computadora
CASE Ingeniería de software asistida por
computadora
CHUI Interfaz de usuario basada en caracteres
COTS Comercial para venta en los canales
convencionales
CRUD Crear, leer, actualizar y eliminar
CSCWS Sistema de trabajo colaborativo soportado por
computadora
CSS Hojas de estilo en cascada
DBMS Sistema de administración de bases de datos
DDE Intercambio dinámico de datos
DFD Diagrama de flujo de datos
DHTML HTML dinámico
DLL Biblioteca de vínculos dinámicos
DSL Línea de suscriptor digital
DSS Sistema de soporte de decisiones
DTD Definición de tipo de documento
EDI Intercambio electrónico de datos
E-R Entidad-relación
EIS Sistema de información para ejecutivos
ERD Diagrama entidad-relación
ERP Planificación de recursos empresariales
ES Sistema experto
ESS Sistema de soporte para ejecutivos
FAQ Preguntas frecuentes
FPC Conteo de puntos de función
FTP Protocolo de transferencia de archivos
GIF Formato de intercambio de gráficos
GUI Interfaz gráfica de usuario
HCI Interacción humano-computadora
HTML Lenguaje de marcado de hipertexto
http:// Protocolo de transferencia de hipertexto
ICTS Tecnologías de comunicación de información
ISDN Red digital de servicios integrados
ISP Proveedor de servicios de Internet
JAD Diseño de aplicación conjunta
JPEG Grupo de expertos unidos en fotografía
KDD Descubrimiento de conocimiento en bases de
datos
KWS Sistemas de trabajo de conocimiento
LAN Red de área local
MICR Reconocimiento de caracteres de tinta
magnética
MIS Sistema de información administrativa
MRP Planificación de requerimientos de materiales
OAS Sistemas de automatización de oficinas
OCR Reconocimiento óptico de caracteres
OID Identificador de objetos
OLAP Procesamiento analítico en línea
OLE Vinculación e incrustación de objetos
OOA Metodología orientada a objetos
OSS Software de código fuente abierto
PERT Técnicas de revisión y evaluación de
programas
PHP Preprocesador de hipertexto; un lenguaje de
programación de código fuente abierto
PKI Infraestructura de clave pública
QBE Consulta por ejemplo
RAD Desarrollo rápido de aplicaciones
SAAS Software como un servicio
SAN Red de área de almacenamiento
SDLC Ciclo de vida del desarrollo de sistemas
SET Transacción electrónica segura
SLA Acuerdo de licencia de software
SOA Arquitectura orientada a servicios
SQL Lenguaje de consulta estructurado
SSL Nivel de sockets seguros
STROBE Observación estructurada del entorno
TAM Modelo de aceptación de tecnología
TPS Sistema de procesamiento de transacciones
TQM Administración de calidad total
UML Lenguaje unificado de modelado
URL Localizador uniforme de recursos
VB.NET Visual Basic .NET, un entorno de
programación de Microsoft
VOIP Voz sobre protocolo de Internet
VPN Red virtual privada
WAN Red de área amplia
WAP Protocolo de aplicaciones inalámbricas
WIMAX Interoperabilidad mundial para acceso por
microondas
WLAN Redes de área local inalámbricas
WMP Windows Media Photo
WWW World Wide Web
XP Programación extrema
XSLT Transformaciones de lenguaje de hojas de
estilo extensiblewww.xlibros.com

ÍNDICE
566
Nota: Los números de página
seguidos por una f cursiva
indican que se trata de una
figura.
SÍMBOLOS
# (libra), 297
* (asterisco), 246, 304, 414,
455
[ ] (corchetes), 232
{ } (llaves), 231
(signo de suma), 231, 246, 298,
383
« » (comillas angulares), 308
(menor que), 244
(signo de igual), 231, 298
(mayor que), 244, 262, 266,
276, 455, 471
— (guión), 297
(signo de resta), 297
() (paréntesis), 232, 298
/ (barra diagonal), 257
A
Accesorios (props) de oficina,
145-46
Acción del usuario, mínima,
459-60
Acciones
árboles de decisión, 271-73
tablas de decisión, 266-71
Actividades comerciales, listado,
207-08, 209f
Actores
acerca de, 36-38, 142
ejercicios, problemas, 54
en diagramas conductuales,
287-88
en diagramas de secuencia,
294-96, 300
en el modelado de casos de uso,
17, 41-43, 314
Administración
de equipos, 83-86
de nivel medio, 44
de proyectos
acerca de, 56
actividades de análisis y
diseño, 83-88
análisis de costos y
beneficios, 72-77
de los proyectos de comercio
electrónico, 86
ejercicios, 92, 94-98
estatutos, 87
fracaso, 87-88
inicio, 56-62
lidiar con la complejidad, 82
necesidades de hardware y
software, 63-72
planeación y control de
actividades, 77-82
programación de proyectos
mediante diagramas de
Gantt, 79-80
propuesta de sistemas, 88-91
selección, 61-62
uso de diagramas PERT,
80-82
viabilidad, 62-63
estratégica, 45
Administración de calidad total
(TQM)
arquitectura orientada a
servicios (SOA) para, 522-23
metodología modular, 520-22
recorridos estructurados,
517-18, 519f
responsabilidad, 516-17
y diseño de sistemas
descendente (top-down),
518-20
y Seis Sigma, 516, 517f
Adobe Dreamweaver, 348
Agente de cambio, 7-8
Agregación, 305
Agrupamiento, como patrón, 431
Ajax (JavaScript asíncrono y XML)
acerca de, 6
definición, 349f
y el diseño de entradas, 387-88
y el particionamiento, 213
y la salida de páginas Web, 358-60
y los diagramas de secuencia,
302-03
Ajuste para HCI, 442-43
Alcance, metodología ágil, 170-71
Almacenamiento. Vea Almacenes
Almacenes
corporativos de datos, 429-32
de datos
contenido, 236-38
desarrollo, 241
metodologías, 403
símbolo, 194f, 195
Vea también Diseño de bases de
datos
American Express, 432
Análisis
de costos y beneficios, 72-79,
546
de flujo de efectivo, 75
de punto de equilibrio, 74-75
de sistemas, 6, 228-58
de valor presente, 75-77
Analista de sistemas
cualidades, 6
deberes, 1, 10
derechos, 181
habilidades requeridas, 20
roles, 6-8
Anomalía(s)
de actualización, 426
de eliminación, 426
de inserción, 426
en las tablas, 425-26
Anuncios, 141
Apertura organizacional, 26
Aplicaciones web híbridas, 468
Árboles de decisiones, 271-73
Archivos de transacciones, 410-11
Archivos maestros, 410, 424-26
Áreas de texto, 381
Arquitectura orientada a servicios
(SOA), 5, 522-23, 533
Arrendamiento de hardware, 67
Artefactos para UML, 311-12
Aseguramiento de calidad,
implementación
acerca de, 515
auditoría, 529
documentación, 523-26
ejercicios, 551-54
evaluación, 546-48
de sitios Web corporativos,
548-50
proceso de prueba, 526-28
y administración de calidad total
(TQM), 516-23
y capacitación de usuarios,
536-39
y conversión de sistemas,
539-41
y cuestiones de seguridad, 542-44
y el desarrollo ágil, 170
y mantenimiento, 528-29
y metáforas organizacionales,
541-42
y planeación de recuperación de
desastres, 544-46
y sistemas distribuidos, 529-36
Asignar prioridades, 59
Asistentes, 464
Asociaciones
como patrones, 431
entre clases, 304-05
Asterisco (*), 246, 304, 414, 455
Atributos
de datos, 34
de entidades, 405-08
en clases, 282-83, 303, 306-08
en consultas, 470-471
en formularios, 417-20
en metodologías O-O, 297-300
en UML, 286-87
funcionales, 343
modificación, 310-11
que no son claves, 413
Auditoría de sistemas, 529
Ayuda, opciones de, 464www.xlibros.com

ÍNDICE 567
B
Banca y recuperación de desastres,
545
Barra
de navegación, 467
diagonal (/), 257
Base(s)
de acoplamiento, 457
de datos
acerca de, 403-05
análisis visual, 446-48
comparación con almacenes
corporativos de bases de
datos, 429
de red, 412
recuperación, presentación de
datos, 424, 427f
relacionales, 404, 411-12
jerárquica, 412
Beneficios
intangibles, 73-74
tangibles, 72-73
Bienestar para HCI, 443
Blogs, 357
Bluetooth, 5
Botones
aumentar/disminuir, 381
básico, 389
de comandos, 381
de navegación, 354, 367
de opción, 380
en el comercio electrónico,
481-82
en el diseño, 380-86, 400-401
en GUI, 460
para validación, 505
Breadboarding (prototipo de
parches), 156
Bugs, 12-13, 170, 518
C
Caché, 354, 355
Cajas de tiempo (timeboxing), 179
Calendarización y planeación de
actividades, 79-82
Campo
en los registros, 408, 501
ocultos, 382
Capa
de acceso a datos, 302
de negocios, 302
Capacidad de uso, 444-48
Capacitación, 536-39
Captura de datos, 136, 138-39,
494-99
Cargas de trabajo, estimar, 64-65
Carriles, 291-94
Carrito de compras, 205, 391
Cartas de presentación, 88
CASE, herramientas. Vea
Ingeniería de software
auxiliada por computadora
(CASE), herramientas
Casillas de verificación, 380
Caso de la CPU
análisis OO, 320-27
diagrama E-R, 437-40
diagramas de flujo de datos,
222-27
diccionarios de datos, 252-58
entrada de datos precisa, 512-14
entrevistas, 128-30
formularios, 399-402
HCI, 479-83
herramientas CASE, 23
Microsoft Visio, Visible Analyst,
51-55, 100-01
prototipos, 186-91
salida, 366-70
seguridad, recuperación de
desastres, 554-56
STROBE, 154
tablas de decisiones, 277-78
CD-ROM, 334
Centro de bibliotecas de cómputo
en línea (OCLC), 495
Cero
a cero, relación, 406-07
a muchos, relación, 406-07
a uno, relación, 406-07
Cerrazón, organizacional, 26
Certificados digitales, 544
Ciclo de vida del desarrollo de
sistemas (SDLC)
comparación
con el modelado ágil, 14-17,
19f, 177-79
con la metodología OO, 17-19
con RAD, 165-66
fases, 8-13
herramientas CASE, 14
prototipos como alternativa,
157-58
y HCI, 9
Clases
abstractas, 299, 307-08
activas, 299
atributos, métodos, 308-11
buscar, 308
de control (activas), 299
de entidad, 299
de interfaz, 299
de límite (interfaz), 299
mensajes entre, 308-09
para el análisis OO, 282-83
relaciones entre, 304-06
tipos de, 299
y tarjetas CRC, 284-86
Clasificación de códigos, 487-89
Claves
de registros
acerca de, 409-10
en diagramas E-R, 408,
421-22
en normalización, 413-23
símbolos, 252
únicas y primarias,
comparación, 424
primarias
almacenadas en cookies, 302
como elemento de estructura
de datos, 238
en los registros, 409-10, 417,
419-26
símbolo, 252
Cliente en el sitio, 171, 176
Codificación de derivación
alfabética, 486-87
Código(s)
de autovalidación (dígitos de
verificación), 501-03
de barras, 498
de función, 491
de secuencia simple, 486
secuencia por bloque, 487
subconjunto de dígitos
significativos, 489-90
y codificación
clasificación, 487
códigos de barras, 498
de cifrado, 488
de derivación alfabética,
486-87
de secuencia en bloque, 487
de secuencia simple, 486
definición, 485
en el desarrollo ágil, 168-69
función, 491
lineamientos, 491-93
mnemónicos, 490
ocultar, revelar, 488-89
subconjunto de dígitos
significativos, 489-90
Unicode, 490
uso, 493
Colección, 305
Color en el diseño de pantallas,
389
Comentarios en un formulario, 372
Comercio electrónico
administrar proyectos, 86
entrada de datos precisa, 506-07
integrar aplicaciones, 4-5
navegación, 465-68
retroalimentación, 465
seguridad y privacidad, 543-44
Comercio-m (comercio móvil), 5
Comillas angulares (« »), 308
Composición, 306
Compra de hardware, 67
Computación en nube, 531-33
Computadora portátil, 457
Comunicación
como valor ágil, 14
diagramas, 296-97, 314
diseñar diálogo, 458-61
eficiencia, 179
en el modelado ágil, 167
en el modelado de casos de uso,
36-38
en equipos, 84-85
oportunidad de consultoría, 46
Vea también Retroalimentación
y DFD, 217
y la planeación de recuperación
de desastres, 545
y tablas, gráficas, 89-91
Condición, condiciones
alternativas, 266-73
de guardia, 309
Construx, 82
Consultas
diseñar, 468-69
lenguaje estructurado para
(SQL), 473-74
mediante ejemplo (QBE),
471-73
tipos, 469-71
Consultor, 6
Consumidores. Vea Usuarios
Contraseñas, 542
Control operacional, 43-44
Controles deslizables, 381
Conversión
directa, 539
gradual, 540
modular, 540
paralela, 540
Corchetes ([ ]), 232
Correo electrónico, 334
Cosas de anotación, 312
Costar, 82
Costos
intangibles, 74
tangibles, 74
COTS. Vea software comercial de
venta en canales
convencionales (COTS)
Crear, Leer, Actualizar, Eliminar
(CRUD), 204, 308, 309f
Cuadrado doble, símbolo, 194
Cuadro(s)
de diálogo, 380-81, 452-53
con controles en pestañas,
380
de lista, 380
de mensaje, 381
de texto, 380
y listas desplegables
diseño, 358, 387, 460
ejercicios, 319, 369-70, 399,
401-02
en el modelado ágil, 187-88
ilustrados, 495
para la navegación, 383
razones para usar, 380-81
utilizados en el análisis,
320-22
Cuellos de botella, 496
Cuerpo de formulario, 372
Cuestionarios
acerca de, 114
administrar, 122
diseñar, 119, 121
elección de palabras, 115-16,
118www.xlibros.com

568 ÍNDICE
planear, 114-15
preguntas abiertas, 115, 116f
usar escalas, 118-19
Cuestiones de costo
como metodología ágil, 14
de prototipos, 157
ejercicios, 98
en compras de software, 68-69
en el modelado ágil, 169-70
riesgos inherentes, 181
tangible, intangible, 74-77
y fracaso, 88f
y viabilidad, 63
Cuestiones financieras. Vea
Cuestiones de costo
Cultura organizacional, 24, 45-46,
180
D
Daltonismo, 450
Datos, vistas físicas y lógicas de,
411-13
Decisiones estructuradas
ejercicios y problemas, 275-76,
279-80
elección de técnica, 273
y árboles de decisiones, 271-73
y español estructurado, 261-65
y tablas de decisiones, 266-71
Decoración, iluminación, 146
Definición
de tipo de documento (DTD),
244-46, 506
del problema, 57-61
Dependencias
parciales, 413-14
transitivas, 413-14
Desarrollador Web, 349
Desarrollo rápido de aplicaciones
(RAD), 163-66
Descubrimiento de conocimiento en
bases de datos (KDD), 429-32
Desempeño para HCI, 443
Desencadenador, 205
Desnormalización, 426-28
Detección de marcas, formularios,
497-98
DEVONthink Professional Office,
147
Diagrama(s)
0
dibujo, 196-97, 210-11
ejemplo, 199f
en los diccionarios de datos,
238-39
y particionamiento, 214f
de actividades
acerca de, 290-92
carriles, 291-94
creación, 292-94
definición, 287
entradas en el repositorio
para, 294
de casos de uso, 287, 288f, 313,
314
de clases
acerca, 297-300
asociaciones, 304-05
definición, 287
ejemplo, 288f
en el modelado de casos de
uso, 314
gen/spec (generalización/
especialización), 306-09
mejora, 303
relaciones todo/parte, 305-06
de componentes, 312
de conectividad
concentradores, 534-35
estaciones de trabajo, 535
de comunicación, 296-97, 314
de descomposición de red,
533-34
de despliegue, 312, 315
de estados, 287, 288f, 309-11,
314
de estructura, 521-22
de flujo de datos a nivel de
contexto
caso de la CPU, 51-55
desarrollo, 195-96, 208-10
expansión, 197f
y descripción de sistemas,
29-30
de flujo de datos (DFD)
caso de la CPU, 222-27
desarrollar, 195-200
ejemplo de, 207-13
ejercicios, problemas, 219-21
errores encontrados, 198-200,
201f
físicos, 202f, 203-06, 212-13,
215f
lógicos, 200-203, 212-13
particionamiento, 206-07, 213
símbolos utilizados, 194-95
usos, 10
ventajas, 193-94
y casos de uso, 205-06
y comunicación, 217
y el modelado de eventos,
205
y especificaciones de
procesos, 260-61
de Gantt, 79-80, 96-97
de modelos de datos, 416f-20f
de secuencia
acerca de, 294-96
capas utilizadas, 302-03
clases utilizadas, 300-02
definición, 287
ejemplo, 288f
mejora, 300-03
para oportunidad de
consultoría, 313
trabajo con, 314
E-R, 421-22
hijos
comparación con proceso
padre, 199f
desarrollo de, 198, 211-12
en diccionarios de datos,
238-39
mejorar, 288f
para el modelado de casos de
uso, 38, 43
para UML, 286-87
PERT, 82, 97, 101
Diccionarios de datos
acerca de, 228-29
almacenes de datos, 236-38, 241
análisis de entradas y salidas,
239-41
caso de la CPU, 252-58
creación, 238-41
ejercicios, problemas, 249-51
elementos de datos, 234-36, 248
estructuras de datos, 231-33, 242f
flujos de datos, 229-31
uso, 242-47
y DFD, 229-30
y español estructurado, 264f
y especificaciones de procesos,
265-66
y XML, 243-47
Dígito de verificación, 409, 501-03
Dinero. Vea Restricciones de costo
DinoTech, 352-53, 352f,
467-68
Discapacidades y HCI, 449-50
Diseño
consistente en el diálogo, 461
de aplicación conjunta (JAD),
111-14, 127
de bases de datos
bases de datos relacionales,
411-13
diseño de relaciones de
archivos maestros/bases de
datos, 424-26
ejercicios, 434-36
normalización, 413-23
objetivos de las bases de
datos, 403-04
realidad, datos, metadatos,
404-10
tipos de archivos para,
410-11
Vea también Almacenes de
datos
de sistemas descendente (top-
down), 518-20
metodología ágil para el, 169
modular de programas, 520-22
Dispositivos portátiles, 348, 375
Documentación y aseguramiento
de calidad, 523-26
Documentos
cualitativos, 140-41
cuantitativos, 136-39
Dominio en bases de datos, 413
Dragon Naturally Speaking, 458f
Duplicación remota sincrónica,
545
DVD, 334
E
Eficiencia en proyectos
estructurados, 177-79
Elementos
base, 205
de datos, 234-36, 248, 408-10,
411f
derivados, 205
Encabezado de un formulario,
372
Entidades
atributos, 408
clases, 299
claves, 409-10
en bases de datos, 405
integridad, 424
registros, 408-09
relaciones, 30-35, 405-08
y flujo de datos a nivel de
contexto, 29-30
Entidad-relación (E-R), modelo
caso de la CPU, 51-55
diagramas, 406f
ejemplo, 407-08
símbolos, 407f
utilizado en sistemas, 30-35
y claves de registro, 421-22
Entrada(s)
acerca de, 485
calidad mediante la validación
de la entrada, 499-506
captura de datos, 494-99
codificación, 485-93
criterios, 371
de acción, 276f, 278
diseño de intranets y de internet,
389, 391
ejercicios para, 508-11
ejercicios y problemas, 394-98
en el comercio electrónico,
506-07
flujos de datos, 260
formularios, diseño de
impresos, 371-76
para Web y pantalla, 376-89
íconos, 378-79
mensajes, 309
retroalimentación, 462-63
y GUIs, 379-82
Vea también Salida
Entrada/salida, formularios de,
454-55
Entregas pequeñas, 171, 175
Entrevistas
acerca de, 103-04
caso de la CPU, 128-30
informe, 109-10
preguntas abiertas, 105-06
preguntas cerradas, bipolares,
106-07
preparación, 104-05
secuencia de preguntas, 107-09
sondas, 107
Equipo de oficina, 145-46
ERP. Vea Planeaciónwww.xlibros.com

ÍNDICE 569
Errores. Vea Bugs
Ética y minería de datos, 432, 544
Escalas, 118-19
Escenario de casos de uso, 287,
288f, 290f, 296
Escuchar
y HCI, 448, 540
metodología ágil, 169
Español estructurado, 261-65,
266f, 273-74
Especificaciones del proceso
acerca de, 259-60
diccionario de datos, 265-66
ejercicios, problemas, 274,
279-80
formato, 260-61
no requeridas, 260
objetivos, 260
Espejos de datos (data mirroring),
545
Esquema, 246-47, 412, 506
Estados Unidos, convenciones de
TI en, 441, 543, 545
Estereotipos, 300
Estilo cognoscitivo, 444-48
Estrategias de conversión,
consideraciones, 539-41
Estructura(s)
de casos, 261, 263f
de datos, 231-33, 242f
de decisión, 261, 263f, 264-65
de embudo, 109
de pirámide, 108-09
en forma de diamante, 109, 110f
secuenciales, 261, 263f, 264
Esun, 307f, 308
Esuntipode, 307f, 308
Evaluación, 546-48
Eventos, 309, 314
diferidos, 310
Experiencias de Hypercase
acerca de, 20
administración de proyectos, 84,
92
cuestionarios, 123
DFD, 218
diagramas, 317
diseño de bases de datos, 433
elementos de datos, 248
entrada de datos, 393-94,
507-08
entrevistas, 112
español estructurado, 274
estrategias de análisis, 47
FOLKLORE, 525
implementación, 551
interfaces, 475
investigación, 141
prototipos, 182
salida, 360
STROBE, 149
Expert Choice, software, 59
Experto de soporte, 6-7
Exploración en el proceso ágil, 15-16
Extensión, relaciones, 37-38
F
FAQ, 353
Fase
de implementación de RAD,
164-65
de planeación de requerimientos
del RAD, 164
Filtrado, 543-44
Firefox, 349
Firewall, sistemas de, 542-44
Firma, verificación de, de
formulario, 372
Flujos de datos, 229-31
de interfaz, 198
FOLKLORE, 523-25
Formas artísticas, 523-25
Formularios
clandestinos, 139
color, 389
copiar, 44
de captura de datos, 100, 136-38
de detección de marcas, 497-98
de entrada/salida, 134, 371-72,
454-55
de negocios, 376-78
diseño de, 213-14, 372-76, 377,
496
en la metodología estructural,
177-78
preimpresos, 331-32, 333
utilidad, 547
Web, 459-60
Foros, 464-65
Fuentes, 333, 347, 375, 448
Funciones de búsqueda, 467-68
G
Gadgets, 347
General Motors, 432
Generalización, 306
relación, 38
Generalización/Especialización
(gen/spec), diagramas de,
306-09
Gráficas, gráficos y predisposición,
340-41
en el diseño de pantallas, 345, 346f
para sitios Web, 354
uso, 90-91
Guión (—), 268
Guión, 142, 143b
Gurús, 168
H
Hardware, 253-54. Vea también
Software
Herencia, 283-84, 306-07
Hipervínculos, 464
Historias de usuarios, 172-74, 175f
Hojas de estilo en cascada, 354-55,
357
HTML, 243-44, 348, 349, 355f
Humildad en el modelado ágil,
167-68
Humor en los documentos, 140-41
I
Íconos, 378-79
Identificación
acceso en formularios, 372
por radio frecuencia (RFID),
489-99
Identificador de objeto (OID), 410
IF-THEN, instrucciones, 267, 272
IF-THEN-ELSE, instrucciones
como español estructurado, 261,
265
en tabla de decisiones, 266
ilustración, 262f, 263f, 264f
uso en la validación, 505
Igual, signo (=), 231, 298
Iluminación de decoración, 146
Impresoras como salida, 331-32
Inclusión, relaciones, 37
Información, 1, 146, 179, 487-89
Informes
archivos, 411
en VA, 254-55
para investigación, 136, 137f
Infraestructura de claves públicas
(PKI), 544
Ingeniería de software auxiliada
por computadora (CASE),
herramientas
acerca de, 14
caso de la CPU sobre, 23
en proyectos estructurados,
177-79
impacto, 229
Instanciamiento, 282
Instrucciones en el formulario, 372
Integración
de sistemas inalámbricos, 5
de sistemas móviles, 5
Integridad
de dominio, 424-25
referencial, 424
Inteligencia artificial (AI), 3
Interacción humano-computadora
(HCI)
acerca de, 9, 11
aplicaciones web híbridas, 468
buena práctica, 450-51
consideraciones físicas, 448-49
determinar las necesidades, 10
diálogo, 458-61
diseñar, 441-42
ejercicios, 476-78
en las entrevistas, 104
interfaces, 451-58
limitaciones, discapacidades y
diseño, 449-50
Vea también Comunicación
y ajuste, rendimiento, bienestar,
442-43
y el análisis visual de bases de
datos, 446-48
y el comercio electrónico,
465-68
y el modelo de aceptación de
tecnología (TAM), 443-44
y la capacidad de uso, 444-51
y la retroalimentación, 461-65
y las consultas, 468-74
Interfaz, interfaces
de apuntar y hacer clic, Vea
Interfaz gráfica de usuario
(GUI), diseño
de lenguaje de comandos, 455,
456f
de lenguaje natural, 451-52
de menús, 453-54
de pregunta y respuesta, 452-53
de programación de
aplicaciones (API), 468
evaluación, 458
gráfica de usuario (GUI)
acerca, 456-57
definición, 379
diseño, 380-82
menús, 454
y captura de datos, 495
para llenar formularios (entrada/
salida), 454-55
plumillas, 457
reconocimiento de voz, 458
sensibles al tacto, 457-58
Inventario de hardware, 64
Investigación, 136-41
Iteraciones, 17, 261, 263f, 265
J
JAD, 111-14, 127
JavaScript
activar, 387
en la distribución páginas Web,
355
y Ajax, 6, 302-03, 349, 358-60
Joomla!, 357
Juego de planeación, 16-17
L
Lenguaje
de acción, 451
de marcado extensible (XML)
proveer estandarización, 299
validar, 506
Vea también Ajax (JavaScript
asíncrono y XML)
y la salida, 357-60
y los diccionarios de datos,
243-47
unificado de modelado (UML)
acerca de, 281
clase, 282-83
conceptos y diagramas,
286-87
diagramas de comunicación,
296-97
fases, 17-19
herencia, 283-84
paquetes y artefactos, 311-12
trabajo con, 313-15
uso para modelado, 315-16
y modelado de casos de uso,
287-90www.xlibros.com

570 ÍNDICE
Ley para estadounidenses con
discapacidades, 449
Leyendas en un formulario, 372-74
Libra (#), símbolo de, 297
Limitaciones y HCI, 449-50
Llaves ({ }), 231
Llenado de formularios, 371, 389
Luhn, fórmula de, 503-04
M
MAC, atractivo de
1Password, 392
acerca de, 12
Bento, 425
DEVONagent, 467
FileMaker Pro, 425
Freeway Pro, 351
OmniFocus, 173
OmniGraffle, 35
OmniPlan, 83
Things, 520
Yojimbo, 147
Mantenimiento de sistemas, 12-13,
17, 528-29
Manuales
de políticas, 141
de procedimientos, 523
Mapa
de imágenes, 381
del sitio, 466
Máscaras (skins) en sitios Web, 390
Mayor que (>), símbolo, 244, 262,
266, 276, 455, 471
Memos, 140-41
Menor que (<), símbolo, 244
Mensaje, definir, 300
Menús, 453-54
con rollover, 466
Metadatos, 404-10, 411f
Metáforas, 140-41, 337, 541-42
Método
definir, 300
determinar, 308-11, 314
en clase de UML, 283
estándar y personalizado, 298
sobrecarga, 298-99
y salida, 330-40
Metodología orientada a objetos
(OOA), 10
MICR (reconocimiento de
caracteres de tinta
magnética), 497
Microsoft
Excel, 444-46
Expression Web, 348
Visio
caso de la CPU, 51-55,
100-01
comparación con
OmniGraffle, 35
ilustración, 353f
usos, 14
Minería de datos, 429-32
Mini especificaciones. Vea
Especificaciones de procesos
Mnemónicos, códigos 490
Modelado
ágil
acerca de, 155
actividades, 168-69
ejercicios, problemas, 183-85
en comparación con SDLC,
14, 19f, 177-79
lecciones de, 175-76
medir el impacto, 181
prácticas básicas, 171, 172f
principios, 168
proceso de desarrollo, 15-17,
171-75
riesgos inherentes, 179-81
valores, principios, 166-68
variables de control de
recursos, 169-71
Vea también Prototipos
de aceptación de tecnología
(TAM), 443-44
de casos de uso
alcance del sistema, 38
caso de la CPU sobre, 51-55
como técnica OO, 287-90
creación de descripciones
para, 43
definición, 35-36
definir, 314
diagramas, 38, 43
durante la resolución de
problemas, 61
escenarios, 38-39, 49
formulario, 205f,
niveles, 39-43
paquetes y artefactos, 311-12
relaciones, 36-38
símbolos, 36
y DFD, 205-06
de espiral, 18-19
de eventos, 205, 206f
de redes, 533-35
Módulo administrable, 159
Motivación, 86
Muchos a muchos (M:N),
relaciones, 405-06, 423,
426-27
Muestra
compleja, 133
estratificada, 133
intencionada, 133
simple, 133
sistemática, 133
Muestreo(s), 132-36
de conglomerados, 133
de conveniencia, 132-33
N
Navegación
intuitiva, 465
Web, 355-56, 465-68
Nivel
de confianza en el muestreo,
134-35
de sockets seguros (SSL), 544
Normalización
diagramas E-R, 421-22
ejemplos, 414-17
formularios, 417-21
pasos, 413-14
y desnormalización, 426-28
Notación algebraica, 231-32
Número de identificación (ID),
230, 234, 237, 299
O
Objetivos/metas, 85-86, 104
Objetos, 309-10
Observación, 142-48
estructurada del entorno
(STROBE), 142-49, 152, 154
OCLC (centro de bibliotecas de
cómputo en línea), 495
OCR (reconocimiento óptico de
caracteres), 496
OLAP (procesamiento analítico en
línea), 429
OmniGraffle, 35
Omniplan, 83
Oportunidades de consultoría
administración de equipos, 85
almacén corporativo de datos, 430
análisis de costos y beneficios, 78
análisis OO, 284, 313, 315
árbol de decisiones, 272
aseguramiento de calidad,
implementación, 518
capacitación, 538
codificación, 492, 494
consultas de bases de datos, 472
contratar ayuda de comercio
electrónico, 7
copias de archivos, 44
cuestionarios, 120, 121
decisión estructurada, 263
desarrollo de un sitio de
comercio electrónico, 26
DFD, 216-17
diccionario de datos, 240
diseño de bases de datos, 404
diseño de formularios, 377, 379
documentación, 524
elegir software, 70, 73
entrada, 390
entrevistas, 108, 110, 113
especificaciones de procesos,
264
evaluación, 548
HCI, 466
interfaces, 454, 456, 457
investigación, 137
muestreo, 135
problemas de comunicación, 46
prototipos, 159, 160, 161, 162
prueba, 528
prueba de validez, 504
retroalimentación, 461
salida, 335
salida para, 339, 342, 348, 356
solución de problemas, 58
solución de sistemas, 546
STROBE, 145
tabla de decisiones, 269
validación de la entrada, 500
Orientado a objetos (OO), análisis
y diseño
acerca de, 17-19, 281
clases, 282-83
diagramas de clases, 297-300
diagramas de secuencia, 287,
288f, 294-96, 300-09
ejercicios y problemas, 318-19,
320-27
herencia, 283-84
modelado de casos de uso, 287-90
objeto, definición, 282
RAD como, 163-66
y tarjetas CRC, 284-86
P
Páginas Web
dinámicas, 383, 386, 395
tridimensionales, 385-87
Pancartas, 141
Pantalla
sensible al tacto, 457-58
para la salida, 332-33
Papel para la salida, 343
Paquetes, 311-12
Paréntesis (()), 232, 298
Particionamiento, 206-07, 213-17
Pata de cuervo, símbolo, 30-31,
405-06
Patrones, identificar, 431
Pegajosidad de los sitios Web, 353
Pensamiento en objetos,
instrucciones, 284-86
PeopleSoft, 162
Periodo de retribución, 75, 77
Persistencia, capa de, 302
PERT, diagramas, 80-82, 97, 101
PKI (infraestructura de claves
públicas), 544
Planeación
de recuperación de desastres,
544-46
de recursos empresariales
(ERP), sistemas de, 5, 28-29
de requerimientos de materiales
(MRP), 28
y control administrativo, 43-44
Plantillas, 352
Plumilla, 457
Polimorfismo, 307
Precisión, 270, 506-08
Predisposición en la salida, 340-44
Preguntas abiertas
acerca de, 105-06
anticiparse a la respuesta, 115
ejercicios, 125
ilustración, 116f, 117f
Preguntas
bipolares, 106-07
cerradas, 106-07, 115, 117f, 125
frecuentes (FAQ), 353www.xlibros.com

ÍNDICE 571
Presentación, capa de, 302
Primera forma normal (1NF),
417-18
Privacidad y comercio electrónico,
544
Procesamiento analítico en línea
(OLAP), 429
Proceso
padre, 198, 199f
primitivo, 198
Programación en pareja, 171, 175-76
Programadores, programación
derechos, 181
lenguaje, 6
productividad, 316
Vea también Orientado a objetos
(OO), análisis y diseño
y retroalimentación, 167
Pronóstico, 72
Propuesta de sistemas, 10-11,
88-91
Protección antivirus, 543
Prototipos
acerca de, 155-56
caso de la CPU, 186-91
como alternativa al SDLC, 157-58
de características seleccionadas,
156f, 157
de parches, 156
desarrollo, 158-60
ejercicios y problemas, 183-85
no operacional, 156f, 157
primero de una serie, 156f, 157
rol de los usuarios, 159-63
tipos, 156-57
Vea también Modelado ágil
ventajas y desventajas, 160-61
y software COTS, 161-62
Proveedor de servicios de
aplicación (ASP), 68
Prueba, 169, 526-28
de cadena, 527
de sistemas completa, 527-28
de vínculos, 527
Puedeserun, 307f, 308
Puesta en producción, 17
Q
QBE (consulta mediante ejemplo),
471-73
QuickBooks Pro, 73
QWERTY, teclados, 449
R
Rango, prueba, 501
Reconocimiento
de caracteres de tinta magnética
(MICR), 497
óptico de caracteres (OCR), 496
Recopilación de información
caso de la CPU, 154
diseño de aplicación conjunta
(JAD), 111-14
ejercicios, problemas, 124-30,
150-52
investigación, 136-41
muestreo, 131-36
observación, 141-48
Vea también Entrevistas;
Cuestionarios
Recorridos estructurados, 517-18,
519f
Rectángulo, símbolo
con extremo abierto, 194f, 195
en diagramas de clases, 297
en diagramas E-R, 407f
preguntas abiertas, 194f, 195
usos, 194-95
Recursos
en la metodología ágil, 176
virtualizados, 531
Red, redes
de área amplia (WAN), 531
de área de almacenamiento
(SAN), 545
de área local (LAN), 531
de área local inalámbricas
(WLAN), 5
de fidelidad inalámbrica
(Wi-Fi), 5, 339-40, 531
Redundancia de datos, 425
Registro
de longitud variable, 409
para investigación, 136, 138f
Registros Web, 357
Regla de los tres clic, 356, 378
Relaciones
de auto unión, 407
en entidades, 405-08
Renta de hardware, 67
Replicación remota asíncrona, 545
Repositorio, 294
de datos, 229-38
Respuesta, 205
Resta, signo de (–), 297
Restricciones de integridad, 424-25
Resumen ejecutivo, 89
Retraso, procesamiento, 463-64
Retroalimentación
acerca de, 461
como control del sistema, 25
como valor de metodología ágil,
167
después de los prototipos, 158
diseñar, 464-65
tipos, 462-64
y precisión, 506-07
RFID (identificación por radio
frecuencia), 498-99
Riesgos de la innovación, 179-81
Rollover, menús, 466
Ropa, 146
RSS, fuentes, 335
Ruby on Rails, lenguaje, 6
S
SaaS (software como un servicio),
531-33
Salida
animada, 333-34
aseguramiento de calidad,
implementación, 526
como audio, 333-34
como CD-ROM, DVD, 334
como tecnología push/pull,
336
como video, 333-34
comparación entre interna y
externa, 331
contenido y método, 330-40
definición, 329
ejercicios y problemas, 361-65
electrónica, 334-36
elegir tecnología, 336-40
flujos de datos, 260
impresa, diseño, 341, 343
impresoras, 331-32
mensajes, 309
objetivos de diseño, 329-30
pantallas, 332-33, 344-47
predisposición, 340-44
producción y XML, 357-60
Vea también Entrada
y las fuentes RSS, 335
SAN (red de área de
almacenamiento), 545
Scrum (melé), 174-75
Secuencias como patrones, 431
Segunda forma normal (2NF), 419
Seguridad
acerca de, 542
conductual, 543
física, 542
lógica, 542-43
y comercio electrónico, 543-44
y partición DFD, 207, 215
Seis Sigma, 516, 517f
Semana de trabajo de 40 horas,
171, 176, 179
Sensibilidad perceptual, 450
SET (transacción electrónica
segura), 544
Símbolo
de flecha, 194, 295-96
utilizados en STROBE, 147-48
Simpleza en el modelado ágil, 167
Sin normalizar, 413-23
Sistemas
de administración de contenido
(CMS), 356-357
de automatización de oficinas
(OAS), 2-3
de información
análisis y diseño orientado a
objetos (OO), 17-19
ciclo de vida del desarrollo
de sistemas, 8-13
elegir, 19
enfoque de utilidad para la
evaluación, 546-48
integrar tecnologías para, 4-5
necesidades de análisis y
diseño, 6
rol de los analistas, 6-8
tipos, 2-4
de información administrativa
(MIS), 3
de procesamiento de
transacciones (TPS), 2
de soporte
de decisiones (DSS), 3
de decisiones en grupo
(GDSS), 3-4
para ejecutivos (ESS), 4
de trabajo de conocimiento, 3
distribuidos
computación en nube, 531-33
modelado de redes, 533-35
tecnología cliente-servidor,
529-31
ventajas y desventajas,
535-36
expertos, 3
organizacionales
comprensión, 24
cultura, 45-46
diagramas de estado, 309-11
flujo de datos a nivel de
contexto, 29-30
interrelación,
interdependencia, 25-26
modelado de casos, 35-43
perspectiva, 27-28
virtuales, 26-27
y el modelo de entidad-
relación, 30-35
y ERP, 28-29
y los niveles administrativos,
43-45
Web, 4-5
Sitios Web
corporativos, 141
diseñar, 348-56
mantener, 356-57
máscaras (skins), 390
particionar, 213-17
promoción, 356
vocabulario para, 349f
SOA. Vea Arquitectura orientada a
servicios (SOA)
Sobrecarga de información
humana, 179
Software
como un servicio (SaaS), 531-33
ejercicios y problemas, 256-57
elegir, 68-72
externalizar, 71
foros, 464-65
para el diseño de formularios, 375
personalizado, 68-69
registros y elementos, 252-53
Vea también Software,
comercial de venta en canales
convencionales (COTS);
Entrada, MAC, atractivo de;
Salida
Software
comercial de venta en canales
convencionales (COTS)
crear prototipos, 161-62www.xlibros.com

572 ÍNDICE
elegir, 68-72
evaluar para comprar, 68-71
para sitios Web, 354
soporte, 539
de código fuente abierto (OSS), 5
Solución de problemas, 57-61
Sondas, 107
Soportado por computadora
sistemas de trabajo colaborativo
(CSCWS), 4
Soporte del distribuidor, 67-68,
71-72
Sprint, 175
SQL (lenguaje de consulta
estructurado), 473-74
SSL (nivel de sockets seguros),
544
STROBE. Vea Observación
estructurada del entorno
(STROBE)
Subculturas organizacionales,
45-46, 49
Suma (+), signo de, 231, 246,
298-99, 383
Supervisión de los empleados, 543
Survey Monkey, 122
T
Tablas, 89-90, 413
archivos de, 410
de decisiones
acerca de, 266-67
comparación con árboles de
decisiones, español
estructurado, 273
desarrollo, 267-68
ejemplo, 269-70, 280f
integridad y precisión,
270-71
de respuestas a eventos, 382-83,
384f
dinámicas, 444-46
Tableau Software, 446-48
Tableros
de anuncios, 141
de control, 346-47
Tablet PC, 457
Táctil y HCI, 448-49
Taller, fase de RAD, 164
TAM (modelo de aceptación de
tecnología), 443-44
Tareas y HCI, 442-43
Tarjetas
CRC, 284-86
de crédito, prueba, 503-04
de proximidad, 498
Teclados, 449, 496
Técnicas de revisión y evaluación
de programas (PERT), 80-82
Tecnología
cliente-servidor, 529-31
pull, 5, 336
push, 336
Tendencias
como patrón, 431
pronóstico, 72
Tercera forma normal (3NF),
420-21
Tiempo de interfaz, 177-78
Tiempo/sincronización
ahorrar, 113
como problema definido, 60-63
de inactividad, 80-81, 92
desencadenadores, 41
en DFD física, 205
en diagramas de secuencia, 295
estimación, 79
estrategias de eficiencia, 177-79
metodología ágil, 169
para crear prototipos, 159
riesgos inherentes, 180
y entrevistas, 104-05, 108
y eventos diferidos, 310
y fracaso, 88f
y la salida, 330
y partición DFD, 206-07
Tipos
de archivos para las bases de
datos, 410-11
de datos, 235f
Todo/parte, relaciones, 305-06
Totales en formulario, 372
TQM. Vea Administración de
calidad total (TQM)
Transacción electrónica segura
(SET), 544
Triturar documentos, 543
Tupla en bases de datos, 413
U
Ubicación
de oficina, 143-44
del escritorio, 144
UML. Vea Lenguaje unificado de
modelado (UML)
Unicode, 490
Unión Europea, convenciones de
TI, 441, 459, 543
Uno a muchos (1:M), relaciones,
405-06, 422-23
Uno a uno (1:1), relaciones,
405-06, 426-27
Usuarios
capacitación, 536-39
consultar, 41
de tecnología de salida,
336-38
diseñar diálogo, 458-61
diseñar salida, 330
entrevistas, 59, 100-101
estilos cognoscitivos, 444-48
historias, 172-74, 175f
interfaces, 160, 451-58
planeación de recuperación de
desastres, 545
precisión, 506-07
reacciones, 181
retroalimentación, 461-65
seguridad y privacidad, 543-44
Vea también Interacción
humano-computadora (HCI)
y evaluación, 546
y JAD, 111
y partición DFD, 206
y prototipos, 157-64
y sistemas, 3-14
y sobrecarga de información,
179
Utilidad
de actualización, 547-78
de lugar, 547
de objetivo, 548
de posesión, 547
de tiempo, 547
V
Validación
códigos, 493
como elemento de datos, 236
de datos de entrada,
transacciones, 500-04
de transacciones de entrada, 500
proceso, 505-06
Valor, valores
en el modelado ágil, 167
en la metodología ágil, 176
inválidos, probar, 501
Verificaciones de referencias
cruzadas, 501
Viabilidad
determinar, 62-63
económica, 63
operacional, 63
técnica, 63
Vínculos jerárquicos, 466
Visible Analyst (VA)
caso de la CPU, 51-55, 100-01
ejercicio, 252-58, 279-80
para crear clases, 299
usos, 14
Visión y HCI, 448, 449
Vista de usuario, 411-12
Visual Page, 355f
VM Fusion, 12
Voz, entrada de, 450
W
Webtrends, 548
Widgets, 347
WYSIWYG, 343
X
XML. Vea Lenguaje de marcado
extensible (XML)www.xlibros.com

1 SISTEMAS, ROLES Y METODOLOGÍAS DE DESARROLLO
1.1 Contratación saludable: se busca ayuda para el comercio
electrónico 7
2 COMPRENSIÓN Y MODELADO DE LOS SISTEMAS ORGANIZACIONALES
2.1 La E de la vitamina E significa E-commerce (comercio electrónico) 26
2.2 Donde hay carbón hay una copia 44
2.3 El poder de la pirámide 46
3 ADMINISTRACIÓN DE PROYECTOS
3.1 El sonido más dulce que haya sorbido 58
3.2 Veni, Vidi, Vendi o Vine, vi y vendí 70
3.3 Vamos a ver a los magos 73
3.4 Comida para pensar 78
3.5 Cuidar los objetivos 85
4 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS
4.1 Fortalezca sus tipos de preguntas 108
4.2 Un vistazo a la superficie 110
4.3 Analista de sistemas, supongo 113
4.4 El cuestionario insoportable 120
4.5 Orden en las cortes 121
5 RECOPILACIÓN DE INFORMACIÓN: MÉTODOS DISCRETOS
5.1 A la caza de una muestra 135
5.2 Una rosa con otro nombre, o Calidad mejor que cantidad 137
5.3 No confíes en su autoestima o no todo se refleja en un espejo 145
6 MODELADO ÁGIL Y PROTOTIPOS
6.1 Los prototipos, ¿son los reyes? 159
6.2 Despejando el camino para los vínculos con los clientes 160
6.3 Incubar un pez 161
6.4 Este prototipo está todo mojado 162
7 USO DE DIAGRAMAS DE FLUJO DE DATOS
7.1 No hay negocio como el negocio de los flujos 216
8 ANÁLISIS DE SISTEMAS MEDIANTE EL USO DE DICCIONARIOS DE DATOS
8.1 ¿Deseas triunfar en el teatro? ¡Mejora tu dicción(ario)! 240
9 ESPECIFICACIONES DE LOS PROCESOS Y DECISIONES ESTRUCTURADAS
9.1 Kit Chen Kaboodle, Inc. 263
9.2 Estructura para amasar 264
9.3 Ahorrar un centavo en Citron Car Rental 269
9.4 Un árbol gratis 272
10 ANÁLISIS Y DISEÑO ORIENTADOS A OBJETOS MEDIANTE EL USO DE UML
10.1 Alrededor del mundo en 80 objetos 284
1 SISTEMAS ROLES Y METODOLOGÍAS DE DESARROLLOÍ
OPORTUNIDADES DE CONSULTORÍAwww.xlibros.com

10.2 Reciclando el entorno de programación 284
10.3 Desarrollo de un sistema fino cuyo plazo de entrega se venció hace
mucho: uso del análisis orientado a objetos para el Sistema de la
biblioteca pública Ruminski 313
10.4 C-Shore++ 315
11 DISEÑO DE UNA SALIDA EFECTIVA
11.1 ¿Tu jaula o la mía? 335
11.2 Una vía correcta, una equivocada y una vía de metro 339
11.3 ¿Debería prohibirse esta gráfica? 342
11.4 ¿Es tu trabajo aburrido? 348
11.5 Un día en el campo 356
12 DISEÑO DE UNA ENTRADA EFECTIVA
12.1 Este formulario puede ser dañino para su salud 377
12.2 Tener todo junto no siempre es lo mejor 379
12.3 Juego de máscaras 390
13 DISEÑO DE BASES DE DATOS
13.1 Enganche su carrito de limpieza a una estrella 404
13.2 Almacenamiento de minerales para la salud, minería de datos 430
13.3 Pérdida de prospectos 431
14 INTERACCIÓN HUMANO-COMPUTADORA
14.1 El espíritu escolar viene en varias tallas 450
14.2 Preferiría hacerlo yo mismo 454
14.3 No me desaceleren 456
14.4 Ésa no es una bombilla 457
14.5 En espera de ser alimentado 461
14.6 Al correr en un maratón, es conveniente saber hacia dónde
se dirige 466
14.7 ¡Eh, mírame! (Repetición) 472
15 DISEÑO DE PROCEDIMIENTOS PRECISOS DE ENTRADA DE DATOS
15.1 Aquí parece una jungla 492
15.2 Pescar un código de verano 494
15.3 Entrar o no entrar: esa es la cuestión 499
15.4 ¿Validan el estacionamiento? 504
16 ASEGURAMIENTO DE CALIDAD E IMPLEMENTACIÓN
16.1 La calidad de MIS no se pone a prueba 518
16.2 Escribir está bien 524
16.3 Estudiando de manera intensiva para su prueba de sistemas 528
16.4 Puede guiar un pez al agua... pero no puede hacer que la tome 538
16.5 El dulce aroma del éxito 546
16.6 Limpiando el nuevo sistema 548www.xlibros.com

DocViewer

Páginas

Anotaciones